XU216-512 THD+N/signal shaking Topic is solved

[pucur]

Hello,
I have been struggling with this strange problem for a few weeks that I have never seen before, so I would appreciate any advice or idea.

We have a cooperation with the MQA and they gave us the FW for our XMOS/Audio project. We are using ES9038 DAC that has integrated jitter eliminator, but even with that, we have some strange behavior on the output.
MCLK=24.**/22.***MHz, I2S communication...
1. With the MQA FW, the signal (1kHz) is shaking a little and THD+N is about 0.4%, after a few minutes THD is good, and the shaking that we see on the oscilloscope/analyzer disappears. And this is a case with any sample rate.
I'm not sure what is the problem THD or Noise because I measure on the analyzer 0.4% noise and low THD, or sometimes the opposite. But when I measure the SNR it is good. All I see is that shaking.
2. With XMOS reference FW (without MQA), the situation is a little different. The output is good for a sample rate <176.4kHz, but for 176.4kHz and higher s.r. I get 0.8%THD+N and after a few minutes it became stable.
3. Everything is at the Tile0: I2S, USB, I2C, QSPI for the flash, MCLK... I tried without gpio pins but the result is the same.

We tried a lot of things but I think that its not an HW problem because DAC works with the SPDIF input and also when we wire the I2S signal from the XU208 processor (I think that's the worse scenario, wires from the board to board and it works). The clock is good, we are using the PLL IC that has 2 MCLK outputs for DAC and XMOS, we have already used it with the XU208 and everything was perfect. I have compared the clocks, I2S signals with the XU208 board and everything is the same. I can't measure jitter but it looks fine, or the same as with XU208.
When we turn on the device and leave it for about 10min and then play the 1kHz, the output has high THD+N (0.4 - 0.8%) at the beginning, so I believe it is not up to the PSU or PLL, it should become stable for that time.
When we turn on the device and play the 1kHz, then stop it, after a few minutes when we play it again it is good.
If we change the sample rate on the analyzer after we get a steady output (good THD+N), it becomes unsteady again and THD+N is >0.4% like from the beginning.
I tried to find a difference in the PSU, I2S, Clocks... before and after the steady output but I didn't succeed.

I got the advice to try to make some kind of jitter eliminator with a FPGA/Latch... But they said that on their board it work fine even without it. I think that I don't need it, same configuration and PCB layout worked perfectly with a XU208.

I must admit that I'm very confused because I tried everything that comes to my mind in this couple of weeks.

[mon2]

Hi. Not an audio developer but wish to share a similar case for another OEM...be sure that your code is not attempting to communicate with I2C bus devices that are not present in your box. If you have such "ghost code" then the I2C IP will keep retrying to ping the missing device(s) numerous times (believe that 2000 is the XMOS default value) before declaring a timeout. This retry cycle will starve the bandwidth from other code runs on the CPU. At the very least, can affect the USB IP timing and perhaps the issue you have raised. It has been a while since we reviewed the source code but believe there is a define for the # of retries that you could reset to 0 or 1 and see if this impacts your outcome. Or just correct the source code to just not communicate with the I2C bus address of the missing device(s).

Please review and share your update on this thread.

[mmar]

Try other DACs or 2xMCLK.

[pucur]

Hi,
I'm using one I2C to communicate with PLL IC and it works well, sending bytes just one time. I don't know is there any other I2C but I don't see it declared in the XN file.
It works the same with 2xMCLK, I didn't try other DACs, this one should work well.
I saw some activity on the QSPI_D3 of flash memory but I believe it is OK because I saw it on the XU208 project too.
Is there anything else I can try?

[mmar]

Check all samplerates without upsampling to 384k, and as you write DAC ES9038 have jitter eliminator , that need MCLK higher as BCLK , but you write MCLK=24.**/22.***MHz, I2S communication. When MCLK equal BCLK internall pll ES need amount of time to lock , and without lock is THD as you see.

[pucur]

Thank you very much mmar.
I've disabled upsampling and made MCLK x2. Now it is good for 176.4/192kHz SR, I can't play 384kHz from the analyzer but will find a way how to test it and maybe increase MCLK more if I need to.