TAS5754M: No audio at 96kHz and loud white noise (Shifter overflow, channels A/B overflow)

Hello Costas,

• Can you show the I2S signals waveform for both 48k/96k.
• Can you provide the I2C init sequence you are using to configure the device. Do you know what HybridFlow configuration you are using?

Best Regards,

Luis

Hey Luis,

Thanks for the prompt response.

So, here I attach the plots of the data for all 3 scenarios described in the original post. The data were captured on the SDIN of the TAS with a Logic Analyser sampling at 16MHz.

A sinusoidal wave of 440Hz frequency was chosen for this test. The following plots were generated by a python script taking as input the CSV files exported from sigrok.

Scenario 1

Scenario 2

Scenario 3

As you can see the data that arrives at the TAS is correct. 

------

The initialization of the TAS module is pretty straightforward.

1. set an eq filter generated from purepath

2. the 3-wire mode looks like that:

        /*
         * 3-wires mode
         */
      if (!_select_page(0)) break;
        // PLL clock source = SCLK
        if (!_write_reg(13, 0x10)) break;
        // Ignore MCLK and MCLK halt detection
        if (!_write_reg(37, 0x18)) break;
        // Set channel DAC data path
        if (!_write_reg(42, 0x11)) break;

3. setting the volume at a certain level (_write_reg(62, db_volume);

----

The TAS5754m in the speaker uses the Hybridflow 4.
However the data are also being transmitted to another device (with TAS5754m-Hybridflow 3) via a wireless communication protocol.

This question actually made me look in the Hybridflow processor datasheet and I saw that HF3,HF4 support up to 48kHz. So that would explain why we are not getting audio in the scenario2 described in the original post.

1. Is there an option to downsample to 48kHz via the TAS5754m?
2. How does that explain the noise coming in the 3rd scenario - when switching back to 48kHz.

Best regards,
Costas

Hello Luis,

I do understand that the TAS wont' reproduce audio coming at 96kHz. What is not clear yet to me is what would be the cause of the white noise? In other words which scenarios would cause a channel shifter overflow or overflow in channel A/B?

Is there a way to downsample via the TAS5754M module?

Could please provide me some more information on that, so as to get a better understanding and proceed with the debugging of the issue.

Furthermore, the speaker supports AC3 codec for surround sound and it is capable of multichannel streaming. The audio in this case is being streamed only at 48kHz. When starting a stream the audio plays correctly and all the channels have the correct data. (verified with the Logic Analyzer). However I do get exactly the same type of noise that I have mentioned above when I either click forward or backward in the progressbar of the media player (through which I am playing a video that has 6 channels surround audio) or when I pause and then press play again.

Would you have any idea what could go wrong there? The TAS in this case again reports channel overflow in channels A & B.

Note:
I would like to highlight the fact that I never get this issue when I am streaming stereo at 48 kHz. I have tried several times to break it but it plays fine.

Looking forward for your answer.

Best,

Costas

Hello Luis,

Thanks for your answer.

Unfortunately we cannot change the Hybrid flow on the system right now since it is part of more broad configuration consisting other speakers that are connected wirelessly.

I do understand that changing the sampling frequency on the fly could cause issues on the TAS. Through, more targeted tests I have seen that the SCLK and LRCLK loose sync when changing sampling rates.
The same happens on the scenario I have described on the last post regarding the AC3 surround test-file  where the noise starts when I click forward or backward in the progress bar of the media player.

Do you think it would make a difference if the SCLK and LRCLK are stopped somehow while the sampling rate is changed?
Would you have any other suggestions?

It should be noted that the digital data are coming from the chip PCM9211PT which is also a TI module. Do you think we could maybe act on that side?

Thanks in advance.

Best regards,

Costas

Hey Luis,

Unfortunately the CLKs are hardwired to the amp and there seems to be no direct access to them. However The digital signal that comes from the TOSLINK input first comes to the PCM8211 module from which the CLKs are also passing through. Is there a way to act on the CLKs at that point of the signal path?

I have managed to mitigate the white noise by trying to detect the overflow on the TAS side fast enough so that I mute the amp and the reboot it. That seems to work relatively ok but it is just a patch and not a solid solution. My question now is if you believe there might be a problem on the i2c bus while trying to detect the overflow. The interval of the detection is now around 50 to 100msec. Are these values safe enough so that they wont cause any break on the i2c bus? We have a couple more modules to which we communicate over i2c. The i2c bus is running at 100kHz on our system.

Best,
Costas

Hi Costas,

It is long history and pls correct me if i have some misunderstanding of this:

1. Scenario 2: White noise comes out in HF4 when playing 96K and overflow is founded;
2. Scenario 3: SCLK and LRCLK loose sync when changing sampling rates;

For scenario 2, i have to say HF4 cannot support 96KHz as below. As you know, Fs determines the maximum time internal mini-dsp can process audio signal.

96K means the time will be down to half of 48KHz, which leads to insufficient time. Then i have to say any half-processed audio may come out and i cannot explain further due to the complex scenario.  

No SRC (sampling rate convert ) function is found here for this issue. May you configure I2S source from 96K to 48K?

As to scenario 3, if possible, it is suggested to configure pre-stage I2S source to support only 48K.

BR,

Alix Wan.

Hello Costas,

For the surround sound case, is your i2s source driving a tdm signal or an i2s signal, how are you sending 2 channels out of 6 in your system? Does the other 4 channels have their own i2s source.

Also in regards to the audio source are you seeing this at multiple different audio levels? If the audio artifact is clipping and that is what is causing the overflow it wouldn't show up at lower audio levels but the main issue seems to be the data due to changing clocks so the Smoothclip wouldn't really be applicable in this situation.

For your i2s source can you clarify what is doing as you are scrolling through the audio? I am seeing some strange behavior with LRCLK in your first image.

Best regards,

Luis

Hi Luis,

1. The signal path is the following. The surround sound is sent over TOSLINK/SPDIF cable from the source which is connected to our system. From there the TOSLINK data go to the PCB9211PT (TI module) and the output is the i2s_PCM_DATA , i2s_SCLK, and i2s_LRCLK. The PCM_DATA together with the clks enter on another module where the 6 channels are decoded (3 i2s_data_lines). The CLKS for alla 3 i2s_data_lines are the ones from the output of the PCM911PT module. 

Now ONLY one (1) of the i2s_data_lines is linked to the TAS5754M together with the clks.

In addition, ALL 3  i2s_data_lines are driven to a 3rd party module on the system that transmits them wirelessly (over Kleernet) to another similar system. The wirelessly transmitted data channesl seem to cause no issue to the TAS of the other devices.

2. As I have seen by thorough testing is that the overflow related to the Smoothclip is different than the one that is causing the issue. See my previous post.  Discrimination between shifter overflow and channel A-B overflow

3. By i2s source do you mean the PC via which I am playing the AC3 test file? Well, as I said, I am scrolling through the audio in the media player and then the i2s clks go a bit "crazy" /lose sync and then they are stable again.

Best,

Costas

Hello Costas,

For the previously provided waveforms was that the output coming from the PCM9211 or from your SPDIF source, could you provide waveforms of both.

Is this i2s clock instability apparent for different audio files that you play and across different media players? It definitely seems like abnormal behavior. Could you tell what the media player you were using and provide the audio file in your initial test.

best regards.

Luis

Hey Luis,

I will try to provide you with waveforms later this week since due to the new lockdown it might be difficult to reach the office.

I have been experiencing the clock instabilities with several ac3 test files and various media players (VLC, default win10 media player).

My most common tests were conducted wtih the default win10 media player and playing one of the files of the dobly digital theater database ( Amaze Dolby AC3 5.1 640 kbps ).

Best,

Costas

Hello Costas,

I will await for you to provide the waveforms. Typically when scrolling through audio you shouldn't see disruptions in the BCLK, LRCLK only changes in the data it might have something to do with the configuration of your audio interface as the TAS5754M cannot operate normally if there is such abnormal I2S clock behavior.

Best regards,

Luis