Help understanding digital audio clocks - Page 1
Forum section: electronics / projects

author: heather
author_rank: Newbie
timestamp: November 30, 2023, 04:20:16 pm
content: Hi all I am stuck trying to understand audio clocking and jitter and wondered if someone can shed some light.I have written a Raspberry Pi Pico firmware that uses PIOs to decode AES/EBU from a digital mic amp and stream it to a PC over USB audio. It works well, the PIO decodes the AES stream's biphase mark and I can record the PCM data in audacity. If I do a loop back (sending AES/EBU out of another PIO and looped back in to my decoder) and play a file out I find that I get the same PCM audio back in bit-perfect, so I know the system is working well.The problem is how to clock a DAC to give an analog output. I could generate a fairly good 48kHz clock from my RP2040 and send this to both the mic amp (over a 'word clock' or using AES output) and also send this clock to the DAC, but......what if I want to sync the DAC to the AES/EBU input? I can generate a 48kHz clock in the RP2040 from the incoming AES stream by toggling a GPIO each time a sync word comes in, but there will necessarily be a bit slip occasionally. Given that the RP2040 runs at 125MHz, and the audio sync words arrive at 48KHz, that means that there might be 2604 CPU clocks or 2605 CPU clocks between each sync word, which is more than 6 nanoseconds of jitter. Most DAC ICs I've seen require audio clocks with at least 10 times less jitter than this.So how do I deal with this? do I need an analog PLL on the output of my recovered word clock? Am I missing something? How do professional audio products deal with this?Thanks very much

author: oPossum
author_rank: Super Contributor
timestamp: November 30, 2023, 04:54:13 pm
content: Quote from: heather on November 30, 2023, 04:20:16 pmMaster word clock or DARS/AES11https://www.bhphotovideo.com/c/buy/WordClock-Syncronization/ci/14835

author: heather
author_rank: Newbie
timestamp: November 30, 2023, 05:04:10 pm
content: Quote from: oPossum on November 30, 2023, 04:54:13 pmsorry to clarify, I dont mean how do professional *systems* deal with this, but internally inside products. how do they turn a relatively jittery recovered clock from something like SPDIF or AES/EBU into something good enough to drive a DAC?

author: heather
author_rank: Newbie
timestamp: November 30, 2023, 05:13:10 pm
content: Maybe I don't explain myself very well, but if we imagine you have a CPU running at 100MHz, and input an external digital audio signal with a 5MHz bit clock, we will get 20 CPU instructions per audio bit that we can use to recover the clock and data.But given that unless we actually clock the CPU directly off of the incoming audio bitstream (which obviously we wont) the two clocks will slip slightly. Sometimes we might get 19 instructions instead of 20 between audio input clocks. Sometimes we might get 21. For recovering the data this is no problem, but it means that out recovered audio clock will necessarily jitter by 1/100MHz = 10 nanoseconds whenever there is a bit slip because we only have an integer number of CPU clocks to play with.So how do we create a nice clean low jitter audio clock output from recovered jittery clock in this case? I guess an external PLL is a necessity?Edit: And yes of course we could generate a clean sample / word clock from the CPU and send it out for the audio device to synchronize too, but what about the case where we want to sync to the audio device itself? Many products seem capable of doing this.

author: oPossum
author_rank: Super Contributor
timestamp: November 30, 2023, 05:26:15 pm
content: The usual solution is to simply clock all the I2S interfaces of the DSP/MCU with the same clock. That could be a recovered clock from SPDIF/AES (via a decoder chip*), an on board clock, or an externally supplied word clock.* TI DIR9001 has a claimed 50 ps jitter.https://www.ti.com/lit/ds/symlink/dir9001.pdfDoing bit-bang SPDIF is unusual.

author: heather
author_rank: Newbie
timestamp: November 30, 2023, 05:34:46 pm
content: Either I'm not explaining myself well or you don't understand me, sorry! I am not bit-banging AES in the traditional sense, I am using a PIO input. This is necessarily governed by the CPU's clock. So while I can recover a word clock from the stream which is long-term very stable, it necessarily oscillates between the two integer factors of the CPU's clock that are closest to the real word clock. For instance 47997hz and 49003Hz.I want to use this recovered clock to drive a DAC and what I am asking is how I turn it into a stable, low jitter clock. I dont want to use external clocking to drive both devices, or a dedicated AES receiver. I already have the bitstream and already have the (jittery but stable) clock. Do I just put it through an off-chip PLL?Digging around comes up with ICs like TI LMK04133 which seem to do what I want, but I don't know if I am barking up the wrong tree.

author: oPossum
author_rank: Super Contributor
timestamp: November 30, 2023, 05:48:01 pm
content: I do understand. You want to remove clock jitter *that you have added* by sampling with an asynchronous clock. I think this is a bad approach. Using DIR9001 or similar will provide a reasonably low jitter clock that can be used for everything (ADC, MCU, DAC).

author: heather
author_rank: Newbie
timestamp: November 30, 2023, 06:05:37 pm
content: Ok so let's imagine a system that isn't AES/EBU, like AES10 MADI where the clock is not embedded in the signal. All AES10 receivers that I saw are capable of recovering a low jitter 48kHz word clock from the 125MHz bit stream despite the fact that there is not a direct relationship between the audio clock and the bit clock i.e. feeding the 125MHz input into a PLL then a fractional divider will not necessarily recover the audio clock. They are necessarily asynchronous receivers. In this case how is a stable clock being recovered?

author: Marco
author_rank: Super Contributor
timestamp: November 30, 2023, 06:07:13 pm
content: You can generate a much better 48 kHz AFAICS. There's clock dividers for PIO with 16.8 bits and the PLLs are generating a 48 MHz clock for USB ... divide by 1000.