XU208 BCLK jitter ES9038PRO

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
User avatar
pucur
Junior Member
Posts: 7
Joined: Thu Nov 30, 2017 9:22 am

XU208 BCLK jitter ES9038PRO

Post by pucur »

Hello,

I know this is an old topic, but please take a moment and read about my problem because I have dedicated a few days to fix this problem.

I saw that BCLK has some jitter even on lower Freq, for example, 3MHz (PCM48), but the output from the DAC is OK. On higher frequencies jitter is higher.

When I increase a sample rate to LRCK=768kHz, CLK=49.152MHz, BCLK=CLK I got an ideal clock on every pin except on BCLK where I have jitter, and output from the DAC look like to have jitter too. Please take a look at the attached pictures.

Is it a problem with a DAC or with the jitter on the BCLK pin? Is it normal what I have got on BCLK (see the picture)? Do I need to configure the ES9038PRO differently, if anyone has more experience with this DAC.
Topics I read are:
http://xcore.com/viewtopic.php?f=37&t=6267&hilit=DSD512
https://www.xcore.com/viewtopic.php?t=5984
and others...
Images.zip
(76.57 KiB) Downloaded 315 times
Images.zip
(76.57 KiB) Downloaded 315 times


User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Post by Caleb »

If you are using a X200 device, your BCLK should be configured as clock output that is divided from mclk. See in audio.xc:

Code: Select all

#ifndef CODEC_MASTER
static inline void doI2SClocks(unsigned divide)
{
#ifndef __XS2A__
    switch (divide)
    {
#if (MAX_DIVIDE > 16)
#error MCLK/BCLK Ratio not supported!!
#endif
#if (MAX_DIVIDE > 8)
             case 16:
                p_bclk <: 0xff00ff00;
                p_bclk <: 0xff00ff00;
...
...
Also, see in audioports.xc:

Code: Select all

#if defined(__XS2A__)
    /* Clock bitclock clock block from master clock pin (divided) */
    configure_clock_src_divide(clk_audio_bclk, p_mclk_in, (divide/2));
    configure_port_clock_output(p_bclk, clk_audio_bclk);
#else
You don't generate the BCLK with bitfields for X200 devices as is required for the L1 devices. This may help you.

It's also important to recognize the outputs of the XMOS IC are not the same as flip-flops directly clocked by mclk. If you use your oscilloscope to monitor XMOS outputs and trigger on a stable signal, you will detect jitter on the order of 2ns. I don't know why. I assume that the XMOS hardware samples external clock inputs (those that increment clkck-blocks) - using the 500MHz system clock. It has to be something like that.

Are you operating your ESS DAC in synchronous mode or are you using the intended "jitter eliminator" mode? For the latter, any jitter on the IIS interface should be unrelated to the DAC's jitter immunity. It uses an ASRC to synchronize the data to the DAC clock domain that should be clocked by a quality crystal oscillator. As long as your IIS interface meets basic setup and hold specifications, I think there's no problem with jitter from the XMOS. There are of course modes by which jitter can influence DAC performance, such as power supply noise. There is no way to eliminate jitter in the XMOS output signals. You could re-clock those signals with external flip-flops (that are clocked by your quiet external mclk).
User avatar
pucur
Junior Member
Posts: 7
Joined: Thu Nov 30, 2017 9:22 am

Post by pucur »

Hello Caleb, thank you for the replay.

I think that a problem was at a foobar that can't play PCM768, when I tried it on Audirvana it was ok. Now I'm struggling with DSD512 Native, I'm not sure can it support it and on which mediaplayer to try it, Audirvana offers DoP, and for Foobar I'm not sure. I know that this configuration cant support DoP512 but I hope that it can Native512.
User avatar
Caleb
Experienced Member
Posts: 82
Joined: Thu Apr 04, 2013 10:14 pm
Contact:

Post by Caleb »

I have no experience with native DSD. We never did implement it in our products. When we considered it a few years ago, it wasn't clear if it was possible with OSX. We've had almost 0 requests for implementing it.

I'm not clear how DoP would work at DSD512 data rates. At a maximum data rate of 8.192mb / second for UAC2 PCM, that's not enough bytes for a stereo PCM FS of 1,411,200Hz - even if you configure for 24 bits/channel rather than 32. I haven't begun to explore the more recent UAC3 extensions. Maybe there's a possibility if the drivers are updated to that spec.



pucur wrote: Wed Mar 11, 2020 9:47 am Hello Caleb, thank you for the replay.

I think that a problem was at a foobar that can't play PCM768, when I tried it on Audirvana it was ok. Now I'm struggling with DSD512 Native, I'm not sure can it support it and on which mediaplayer to try it, Audirvana offers DoP, and for Foobar I'm not sure. I know that this configuration cant support DoP512 but I hope that it can Native512.
User avatar
Wavelength
Experienced Member
Posts: 76
Joined: Mon Sep 24, 2018 9:56 pm

Post by Wavelength »

Pucur,
At those data rates you really have to have equal trace lengths for your I2S and they cannot be very long. I found a simple FPGA (I use a Lattice ICE40) near the XMOS for those speeds and dejitter code (in the FPGA) and then clock out using the clean MCLK to the ESS DAC chip made a huge difference. Since the XMOS cores (threads whatever) are running time multiplexed it does create a large amount of jitter as Caleb mentioned. Running 768 or DSD512 native would be very hard on the XU208. You may want to add on the I2S treads a high priority to assure the I2S output thread has enough processing time. If you look at the SPDIF schematics on the XMOS dev boards you can see that the line is reclocked with the selected MCLK before it goes out. You can add reclocking like that, but in my experience even with DoP at 352.8 we saw problems as did other companies I work with having bit issues with the headers.
Caleb, hope you are well!
Thanks,
Gordon
Wavelength Audio, ltd.
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Much of the BCLK jitter is actually due to the 100 MHz clock that drives the clock division and IO circuitry; the IO has finite resolution (10ns). So you'll see that the each high period or low period of a clock output is some multiple of 10ns, but over time the average is whatever it should be.
Post Reply