@Markw4 thank you for the long reply, that's exactly what I`m trying to internalize. These recommendations seem so logical and simple but are hard to master.
I have read a lot about current return paths and displacement currents lately and although I have some basic understanding from my studies this is a very extensive topic and the more I learn, I realise I just don't know enough.
Designing according to the rules you described helped me a lot during drawing schematics and PCB layouts and hopefully is reflected in the pictures I posted.
I'm very happy with the progress I'm making so far 🙂
I have read a lot about current return paths and displacement currents lately and although I have some basic understanding from my studies this is a very extensive topic and the more I learn, I realise I just don't know enough.
Designing according to the rules you described helped me a lot during drawing schematics and PCB layouts and hopefully is reflected in the pictures I posted.
I'm very happy with the progress I'm making so far 🙂
Another day, another topic. This time MCK and where to get it.
You suggested that I don't rely on the MCK provided by the MCU and rather have a dedicated clock. The ES9033 Datasheet provides a table with possible hardware configurations for interfacing with an I2S source.
I have to admit that I do not fully understand the pros and cons of using a dedicated MCK vs. PLL, using I2S, left justified or DSD. and how to set it up correctly, but trying read into it atm. For the sake of simplicity, I will narrow it down to using I2S because I bought a teensy 4.1 recently for test purposes and interfacing with it via i2s is very easy, it supports i2s-master and i2s-slave too.
The ESS datasheets provide some challenges in understanding the functions though, I may have overlooked something but haven't found a description of what DRE is. I'm reading the Datasheet of the PCM5242 to have a better understanding of the ES9033, it looks like ESS just doesn't want me to understand their product.
The biggest question I have right now is how much flexibility I should include in the prototype regarding the hardware modes.
If I aim for best performance I think I should use a mode with i2s master or slave with external MCLK and DRE (whatever it is). I assume that is easier to interface some sources using slave mode, but that should not be the deciding factor for the start. Another reason might be if other ADCs or DACs will be added later on, this causes problems for the Teensy at least.
Now to the important stuff: can you give me some pointers for the implementation of the clock? The reference Schematic has a note that MCLK should be 45.158 Mhz or 49.152Mhz but there is no further information why. Using HW M8 with Fs of 44.1Khz (what the teensy provides) would result in:
So why should I use a clock with a specific frequency?
The other option would be to use modes 9-11 with BCK derived from PLL, this is easier to implement but gives me fewer options to test the DAC.
So the question is how to choose the Clock then, using a 49.152 clock would result in a matching FS for MW Mode 1-3 and is at the maximum what is recommended. Would that be reasonable?
The second question I have is what clock I have to get. Just a clock oscillator like this? supplied from the same 3v3 rail? I`m just tipping my toe into the topic, sorry if this is a stupid question.
Best
Fabian
You suggested that I don't rely on the MCK provided by the MCU and rather have a dedicated clock. The ES9033 Datasheet provides a table with possible hardware configurations for interfacing with an I2S source.
I have to admit that I do not fully understand the pros and cons of using a dedicated MCK vs. PLL, using I2S, left justified or DSD. and how to set it up correctly, but trying read into it atm. For the sake of simplicity, I will narrow it down to using I2S because I bought a teensy 4.1 recently for test purposes and interfacing with it via i2s is very easy, it supports i2s-master and i2s-slave too.
The ESS datasheets provide some challenges in understanding the functions though, I may have overlooked something but haven't found a description of what DRE is. I'm reading the Datasheet of the PCM5242 to have a better understanding of the ES9033, it looks like ESS just doesn't want me to understand their product.
The biggest question I have right now is how much flexibility I should include in the prototype regarding the hardware modes.
If I aim for best performance I think I should use a mode with i2s master or slave with external MCLK and DRE (whatever it is). I assume that is easier to interface some sources using slave mode, but that should not be the deciding factor for the start. Another reason might be if other ADCs or DACs will be added later on, this causes problems for the Teensy at least.
Now to the important stuff: can you give me some pointers for the implementation of the clock? The reference Schematic has a note that MCLK should be 45.158 Mhz or 49.152Mhz but there is no further information why. Using HW M8 with Fs of 44.1Khz (what the teensy provides) would result in:
So why should I use a clock with a specific frequency?
The other option would be to use modes 9-11 with BCK derived from PLL, this is easier to implement but gives me fewer options to test the DAC.
So the question is how to choose the Clock then, using a 49.152 clock would result in a matching FS for MW Mode 1-3 and is at the maximum what is recommended. Would that be reasonable?
The second question I have is what clock I have to get. Just a clock oscillator like this? supplied from the same 3v3 rail? I`m just tipping my toe into the topic, sorry if this is a stupid question.
Best
Fabian
DRE: https://www.ti.com/lit/an/sbaa491a/sbaa491a.pdf?ts=1662046026995&ref_url=https%3A%2F%2Fwww.google.com%2F ...For ES9033, DRE is configured in the I2C registers.
Regarding ES9033 clock modes, many ESS dac chips feature an internal ASRC with DPLL (digital phase locked loop). ES9033 appears to have an APLL instead (analog phase locked loop). IMHO the APLL choice is probably for cost savings at the expense of reduced performance. IIRC in general PLLs tend to be more jittery than the digital PPLLs used in ASRCs. https://www.analog.com/media/en/training-seminars/tutorials/mt-086.pdf
In any case most ESS dac chips have the ability to operate in synchronous mode where a PLL and or DPLL is not needed. The reason for two clocks in synchronous mode is because there are two clock families in common use for digital audio. There is the 44.1kHz family and the 48kHz family. Other clock frequencies are multiples of the two common families. A table of commonly used clock frequencies can be found at: https://en.wikipedia.org/wiki/Crystal_oscillator_frequencies ...As can be seen, some of the frequencies are used for audio. The reason for those exact frequencies because they are exact integer multiples of the basic clock family frequencies. For PCM, numbers like 44.1kHz are referred to as the frame sample rate (fs or Fs, etc.). MCLK frequencies are often something like 256Fs, some integer power of 2, times Fs. For DSD, the frame sample rate is the same as the BCLK frequency. PCM frame clock may also be referred to as LRCK (Left/Right clock).
Anyway, if we want the dac to operate in synchronous mode we need two clocks. The higher the standard audio clock frequencies we use, the higher audio sample rates we can play back. The downside if higher clock frequencies is higher close-in phase noise. For ESS dacs, higher clock frequencies may increase harmonic distortion.
For USB audio, its possible to run the USB board from the dac clocks (or maybe from multiplied or divided dac clocks, depending on what the USB board needs). In that case no PLL or ASR is needed.
OTOH SPDIF signals tend to be jittery so its often preferable to use ASRC (or else FIFO buffering) to minimize jitter. PLL tracking of the embedded SPDIF clocking is usually the worst choice.
EDIT: the reason for putting MCLK oscillators next to the dac chip is because they are the dac's analog time reference. Any errors in clock edge timing will affect the audio quality. Other subsystems don't care about jitter if what they are doing is purely digital processing. Jitter only is only critical when the MCLK is used as an analog time reference. That happens in ADCs, DACs, and ASRCs, for some examples. OTOH a DSP chip is often doing purely digital calculations (unless perhaps it is also doing something like ASRC).
Regarding ES9033 clock modes, many ESS dac chips feature an internal ASRC with DPLL (digital phase locked loop). ES9033 appears to have an APLL instead (analog phase locked loop). IMHO the APLL choice is probably for cost savings at the expense of reduced performance. IIRC in general PLLs tend to be more jittery than the digital PPLLs used in ASRCs. https://www.analog.com/media/en/training-seminars/tutorials/mt-086.pdf
In any case most ESS dac chips have the ability to operate in synchronous mode where a PLL and or DPLL is not needed. The reason for two clocks in synchronous mode is because there are two clock families in common use for digital audio. There is the 44.1kHz family and the 48kHz family. Other clock frequencies are multiples of the two common families. A table of commonly used clock frequencies can be found at: https://en.wikipedia.org/wiki/Crystal_oscillator_frequencies ...As can be seen, some of the frequencies are used for audio. The reason for those exact frequencies because they are exact integer multiples of the basic clock family frequencies. For PCM, numbers like 44.1kHz are referred to as the frame sample rate (fs or Fs, etc.). MCLK frequencies are often something like 256Fs, some integer power of 2, times Fs. For DSD, the frame sample rate is the same as the BCLK frequency. PCM frame clock may also be referred to as LRCK (Left/Right clock).
Anyway, if we want the dac to operate in synchronous mode we need two clocks. The higher the standard audio clock frequencies we use, the higher audio sample rates we can play back. The downside if higher clock frequencies is higher close-in phase noise. For ESS dacs, higher clock frequencies may increase harmonic distortion.
For USB audio, its possible to run the USB board from the dac clocks (or maybe from multiplied or divided dac clocks, depending on what the USB board needs). In that case no PLL or ASR is needed.
OTOH SPDIF signals tend to be jittery so its often preferable to use ASRC (or else FIFO buffering) to minimize jitter. PLL tracking of the embedded SPDIF clocking is usually the worst choice.
EDIT: the reason for putting MCLK oscillators next to the dac chip is because they are the dac's analog time reference. Any errors in clock edge timing will affect the audio quality. Other subsystems don't care about jitter if what they are doing is purely digital processing. Jitter only is only critical when the MCLK is used as an analog time reference. That happens in ADCs, DACs, and ASRCs, for some examples. OTOH a DSP chip is often doing purely digital calculations (unless perhaps it is also doing something like ASRC).
Last edited:
As far as I can tell Teensy 4.1 (or the MCU it uses) does not cater for external MCK.
This is a property of USB-I2S board, not USB audio. Some USB-I2S boards have the option of using external MCK, some don't.
A little more on clock oscillators: Usually we try to use low-phase noise clocks for dacs. So-called 'standard' clocks are not usually rated for low phase noise. Some good quality, low cost, low phase noise clocks are made by NDK, particularly the SDA series. They are available in small quantities from diyinhk: https://www.diyinhk.com/shop/audio-...5792mhz-ultra-low-phase-noise-oscillator.html
Clean power for clocks and clock buffers helps them remain stable and low in phase noise. Linear bypass caps may help too, although linear caps may have low enough ESR so that they require separate series or parallel damping resistors to prevent ringing on the power rail. Typically I use a dedicated regulator for clocks.
USB boards that I typically use might include I2SoverUSB and or Amanero. Both types can run on their own clocks or on external clocks. Probably most USB boards could be hacked to run from external clocks, but that's maybe not the most desirable situation. I2SoverUSB requires clean +5v power for best performance. Amanero USB boards (the real ones made in Italy, anyway) can run from USB power, although some people prefer to modify them to run from clean +5v power. The modification is very simple.
Clean power for clocks and clock buffers helps them remain stable and low in phase noise. Linear bypass caps may help too, although linear caps may have low enough ESR so that they require separate series or parallel damping resistors to prevent ringing on the power rail. Typically I use a dedicated regulator for clocks.
USB boards that I typically use might include I2SoverUSB and or Amanero. Both types can run on their own clocks or on external clocks. Probably most USB boards could be hacked to run from external clocks, but that's maybe not the most desirable situation. I2SoverUSB requires clean +5v power for best performance. Amanero USB boards (the real ones made in Italy, anyway) can run from USB power, although some people prefer to modify them to run from clean +5v power. The modification is very simple.
Theoretically yes but in practice I have found quite some devices that have less jitter when using them with SPDIF (as compared to USB).
USB is not the holy grail and SPDIF is far from over. If there is one interface that could leave the building it would be Toslink. Worst of all when used as commonly done.
What I have found is that generating low-jitter MCK from SPDIF is very difficult. So DACs requiring MCK have higher jitter with SPDIF. For those DACs properly implemented asynchronous UAC (or adaptive) has much less jitter than SPDIF.
A proper USB implementation can always beat SPDIF for jitter. That includes for dacs that don't require MCLK.
Why? Please consider than a SPDIF source device always has a clock. The SPDIF signal arriving at a dac board will always be higher jitter than the SPDIF source device clock. There is nothing lower jitter than a properly implemented crystal clock right next the dac chip. Of course if PC EMI/RFI noise makes its way through a USB board and pollutes the dac ground, power, and or clocks, then there is a problem with the USB board to dac implementation.
However, have to agree that for simple SPDIF verses simple USB board implementations, in particular for dacs that don't require MCLCK, in that case SPDIF might end up working better.
Why? Please consider than a SPDIF source device always has a clock. The SPDIF signal arriving at a dac board will always be higher jitter than the SPDIF source device clock. There is nothing lower jitter than a properly implemented crystal clock right next the dac chip. Of course if PC EMI/RFI noise makes its way through a USB board and pollutes the dac ground, power, and or clocks, then there is a problem with the USB board to dac implementation.
However, have to agree that for simple SPDIF verses simple USB board implementations, in particular for dacs that don't require MCLCK, in that case SPDIF might end up working better.
I was thinking of a hardware hack...
Remove the USB board clocks and inject dac clock signals at the empty pads. If necessary use the dac board clock enable pin signals to gate the dac clock signals. Almost as easy as using external clocks with Amanero which otherwise can require re-flashing the firmware.
I think it is not strictly needed, but there is at least a GPIO for that. I looked up the datasheet of the MCU and it provides MCLK as in and out. The implementation of the teensyduino also includes full i2s as master and slave, thats good enough for me, at least for now, while I focus more on DAC side.
I assume that I can't choose a clock by just looking at the datasheet looking for low phase noise and "audio application" but there are similar products listed at mouser.
Maybe it would be reasonable to get one of these XMOS boards from diyinhk for testing.
Regarding clocks, I would suggest NDK SDA which are known as being very good for audio. Other than that, Crystek 957 clocks can be excellent if carefully implemented. They cost more than NDK however. Some other 'low jitter' clocks are only rated for phase noise/jitter down to 12kHz. Ideally dac clocks should be rated as low phase noise down to 1Hz or 0.1Hz offset from the carrier. That is to say, the 'carrier' is the nominal clock frequency. The offset phase noise number refers to the the nominal clock frequency plus or minus the offset frequency. Its that way because clocks tends to spend most of the time pretty near to their nominal frequency and less time at frequencies far away from the nominal frequency. For that reason low offset frequencies tend to have higher phase noise numbers. Clocks rated as low jitter starting from 12kHz offset are good for some communications systems applications, but not what we would most prefer for a dac clock.
Regarding USB boards, for stereo playback I would recommend I2SoverUSB. IME nothing better for diy. Its built-in clocks are NDK SDA but buffered by a CPLD so pretty good but not great clocking. 2nd choice would Amanero run from clean +5v power and with external clocks. The best diyinhk USB board could be a good choice if multi-channel I2S playback and or I2S inputs are required. IME diyinhk clocking is not the most well implemented even when they use NDK SDA clocks. For that reason I might consider hacking its clocks as I suggested in an earlier post. Also diyinhk USB boards are not galvanically isolated like I2SoverUSB is (i.e. they have built-in digital isolators followed by reclocking in CPLD).
Regarding USB boards, for stereo playback I would recommend I2SoverUSB. IME nothing better for diy. Its built-in clocks are NDK SDA but buffered by a CPLD so pretty good but not great clocking. 2nd choice would Amanero run from clean +5v power and with external clocks. The best diyinhk USB board could be a good choice if multi-channel I2S playback and or I2S inputs are required. IME diyinhk clocking is not the most well implemented even when they use NDK SDA clocks. For that reason I might consider hacking its clocks as I suggested in an earlier post. Also diyinhk USB boards are not galvanically isolated like I2SoverUSB is (i.e. they have built-in digital isolators followed by reclocking in CPLD).
Last edited:
Ty for the suggestion. I won't get one right away but will eventually when I`m in need of more comprehensive tests beyond checking functions.
regarding the clock, I see no reason to not follow your recommendation right away, eliminating possible problems. Increased BOM cost isn't a huge issue when buying small quantities and the implementation should be pretty much the same as other clocks with similar specs. I just have to see if I can get my hands on one of those NDK SDAs.
Have a nice weekend everyone 🙂
You obviously don't understand what built-in firmware is. No hardware hack helps and that firmware cannot be re-flashed.
External MCK for DAC is not of much use unless MCU uses it as well. If DAC is I2S master then MCU may not need MCK as BCK and LRCK come from DAC. But having DAC as I2S master may be tricky with USB audio.
Maybe it is recommendable to avoid both SPDIF and USB altogether and bring an audio playback device/streamer directly to a DAC via I2S. No need to worry about nasty interfaces then. If a single board design is done then only the speaker wires and LAN are left 🙂
Last edited:
Exceptions seem to confirm the rule 🙂 You omitted one sentence "Worst of all when used as commonly done." Of course there are implementations that work out very good but more common is jitter well into the 500 ...900 ps region. Please see EC Designs and Johns way of dealing with Toslink.
And eh... there is also a device that transmits data via Toslink. Apparently that Topping DX7 Pro does something very well with Toslink but this sure is not standard. The DX7 Pro seems to be worth its 750 Euro. Quite some money considering one can buy an excellent audio player with built in DACs for less.
And eh... there is also a device that transmits data via Toslink. Apparently that Topping DX7 Pro does something very well with Toslink but this sure is not standard. The DX7 Pro seems to be worth its 750 Euro. Quite some money considering one can buy an excellent audio player with built in DACs for less.
Last edited: