Some people still like to use AK4137 for conversion of PCM to DSD256.
Also, Benchmark used SCR4392 in their DAC-3 to convert all PCM to around 211kHz PCM. From the ASRC it went into a custom FPGA filter, then to the ES9028PRO dac chip (which they programmed to do ASRC one more time). It sounded good and measured good back when DAC-3 first came out.
Whether or not it "makes sense" in other cases depends on what someone's model of the overall system includes. Trying the reclocking and isolation scheme with other dacs (along with shielding for radiated EMI/RFI) will IMHO and IME show that we have often been relying on overly simplistic models of how to make a better dac.
Last edited:
Mark, I am not saying anything against ASRC. E.g. that Benchmark DAC has SPDIF inputs which by principle cannot do I2S synchronous to some internal MCLK.
Just IMO reclocking (along with plain FIFO) is sometimes being used in hifi audio (I do not see that in professional audio) in situations where slaving the I2S transmitter would be technically correct instead. Like many RPi hats (which you rightfully dislike) which FIFO + reclock with precise clock instead of simply feeding the MCLK to their DAC and slaving the I2S transmitter. Obviously the by-design extremely jittery RPi3-4 internal I2S clock benefits from subsequent FIFO+reclocking.
I am afraid the main reason is those vendors do not want to handle the software driver setup required to switch the peripheral to slave mode and use these complicated "workarounds" instead. One can tell that when looking at the RPi audio-hat drivers source code - many are almost copy/paste from some initial version and very very few actually switch the I2S interface to slave, using fully the potential of the external clock.
A setup with master I2S -> FIFO (i.e. huge latency or early buffer issue) -> precise MCLK -> DAC chip is quite often to see, instead of the logical and low-latency MCLK -> DAC chip I2S master -> slaved I2S data transmitter.
But that's already off topic, hats off to your nice project.
Just IMO reclocking (along with plain FIFO) is sometimes being used in hifi audio (I do not see that in professional audio) in situations where slaving the I2S transmitter would be technically correct instead. Like many RPi hats (which you rightfully dislike) which FIFO + reclock with precise clock instead of simply feeding the MCLK to their DAC and slaving the I2S transmitter. Obviously the by-design extremely jittery RPi3-4 internal I2S clock benefits from subsequent FIFO+reclocking.
I am afraid the main reason is those vendors do not want to handle the software driver setup required to switch the peripheral to slave mode and use these complicated "workarounds" instead. One can tell that when looking at the RPi audio-hat drivers source code - many are almost copy/paste from some initial version and very very few actually switch the I2S interface to slave, using fully the potential of the external clock.
A setup with master I2S -> FIFO (i.e. huge latency or early buffer issue) -> precise MCLK -> DAC chip is quite often to see, instead of the logical and low-latency MCLK -> DAC chip I2S master -> slaved I2S data transmitter.
But that's already off topic, hats off to your nice project.
Pavel, Agreed that the clock master logic you describe does make logical sense in terms of avoiding a need for reclocking (although isolation and shielding would still be on the table). However, IIUC only ESS dac chips support I2S bus mastering. OTOH, many professional dacs use AKM chips (such as AK4493, which is not even a top of the line model). Maybe goes to show that the finest possible SQ is not necessarily always the most important factor for professional use. Rack mounting, balanced I/O, etc., may be needed too, all at some affordable price point.
Anyway, for high quality general purpose use (the aim here), I think we need to be able to reclock at least some I2S signals before going into a dac. So we just need to solve any problems that may come up along the way. I feel confident we can figure it out.
Anyway, for high quality general purpose use (the aim here), I think we need to be able to reclock at least some I2S signals before going into a dac. So we just need to solve any problems that may come up along the way. I feel confident we can figure it out.
Last edited:
My mistake, I considered the I2S-master capability a standard in codecs. Apparently AKM codecs can be slaves only. Newer TI codecs seem to be more flexible. BTW it's fun reading their datasheets, adjusted for the politically-correct terminology. No occurence of the word "slave", some left occurences of "master", some occurences of their new controller/target mode terminology. Actually quite confusing as is now, IMO - e.g. https://www.ti.com/lit/ds/symlink/tad5242.pdf
BTW the new RPi5 (as well as majority of standard ARM SoCs) has the I2S MCLK available on GPIO pin, configurable as output (internal clock, finally clean integer division from PLLed GHz clk, no jittery divider like in the previous models) as well as input. IMO the external MCLK input for I2S master is the optimal method as it keeps minimum clock skew between clock and data lines of the I2S bus, important at high samplerates - especially when going through delaying galvanic isolators.
BTW the new RPi5 (as well as majority of standard ARM SoCs) has the I2S MCLK available on GPIO pin, configurable as output (internal clock, finally clean integer division from PLLed GHz clk, no jittery divider like in the previous models) as well as input. IMO the external MCLK input for I2S master is the optimal method as it keeps minimum clock skew between clock and data lines of the I2S bus, important at high samplerates - especially when going through delaying galvanic isolators.
AK4499 (or actually AK4191) can be I2S master also. Reclocking of I2S signals for DS dacs is not needed. For AKM dacs it will easily lead to problems as BCK and LRCK edges need to be at least 5ns apart.
Problems may occur whether or not reclocking is used. Either way if problems occur then they need to be fixed. A couple of inverters in series after a reclocker may give a few ns delay and retain very low jitter. Substrate-coupled-noise in dacs is real. Reclocking some but not all I2S signals might give the desired 5ns if its not already present. It all depends on the specific case. Designing a reclocker with optional 5ns delays selectable on all channels would be easy enough. Don't find that tuning line damping/timing for each dac I2S signal is necessarily futile; Wadia knew about that a long time ago but people forget the tricks. Also, it is strongly recommended that people wanting to work with dacs have at least a 100MHz, 2-channel scope. Sometimes troubleshooting is necessary.
Last edited:
I would assume only the rising edge of BCK would count as IIUC it should be the edge used for reading data line and LRCK values. If the LRCK edges are aligned with BCK falling edge (as is on all I2S charts), there should be plenty of time until the BCK rising edge. How does reclocking make that worse? Thanks a lot for detailing.
IMO if BCK rising edge is aligned with LRCK, such BCK signal does not conform to standard I2S specs, already before reclocking. BCK rising edge triggers the receiver to read and the other lines should be stable at that moment. That's my understanding of I2S timing - falling edge writing, rising edge reading.
Some devices (both interfaces and codecs) allow negating BCK which can be handy for high samplerates where large skews between BCK and data can already occur.
Last edited:
Well then such reclocking is broken, of course. But e.g. reclocking 192kHz BCK 64xfs (i.e. 12MHz - half period 40ns) with synchronous 49MHz (half period 10ns) should not get the BCK rising edges 5ns close to LRCK edges.
Nevertheless, I also fail to see benefits of reclocking I2S with a MCLK signal for DS converters where the same MCLK signal is passed to the chip's MCLK input.
Nevertheless, I also fail to see benefits of reclocking I2S with a MCLK signal for DS converters where the same MCLK signal is passed to the chip's MCLK input.
I would just point out that the clock board has buffered outputs such that a reclocker could be driven at either 22/24MHz or 45/49MHz, as needed. In the latter case the dac board should be operated with 45/49MHz clock modules/oscillators.
As to whether or not there is any audible benefit to reclocking I2S signals, part of developing better dacs involves performing experiments to see what works in practice as opposed to what simplified theoretical models and or datasheets say.
Also, at this point I look at datasheets as being more like resume's designed to give reasons for why you should give a prospective part a place in your short list, and or why even go on to try it it in a prototype device. The IC manufacturer marketing departing may have a lot of say about what is revealed in a datasheet and what will remain confidential. I no longer trust that datasheets will tell me the whole truth about a part any more than I believe a resume from a prospective employee will tell me the whole truth about that person.
As to whether or not there is any audible benefit to reclocking I2S signals, part of developing better dacs involves performing experiments to see what works in practice as opposed to what simplified theoretical models and or datasheets say.
Also, at this point I look at datasheets as being more like resume's designed to give reasons for why you should give a prospective part a place in your short list, and or why even go on to try it it in a prototype device. The IC manufacturer marketing departing may have a lot of say about what is revealed in a datasheet and what will remain confidential. I no longer trust that datasheets will tell me the whole truth about a part any more than I believe a resume from a prospective employee will tell me the whole truth about that person.
Last edited:
According to the version of the I2S standard that I have read, the transmitting side can use either the rising or the falling edge, just as long as the hold time of the data and word clock with respect to the rising bit clock edge is at least 0 ns.
Hi Mark (and others here),
I have been thinking about this and I am not sure I can add that much to the discussion other than saying that IMHO what would be most interesting would be if it were possible to e.g. use a 5.6 MHz oscillator with e.g. the JLSounds board and then be able to align the BCLK & LRCK edges output from the JLSounds board. In this way such a setup could be used in most all cases and for example also with an R2R DAC with the full benefit of the low phase noise of the lower frequency oscillator.
However, as far as I can see this would require a "continuous" adjustment of edges to comply with all the various sampling frequencies when those are shifted.
I reckon it could be done maybe e.g. with a double PLL - maybe something like this:
- The first PLL is the one in the clock multiplier which locks onto the incoming lower frequency reference clock. This reference clock is then multiplied to 45/49 MHz and output to the USB board in question (e.g. the JLSounds board) which I guess also has a PLL ... ?
- The second PLL is a (much) slower PLL which slowly aligns the desired edges without causing the neither the JLSounds board or the multiplier PLL to detect a "clock malfunction" and therefore terminate the data transmission.
This would have to work for all relevant frequencies of reference clock(s) and sampling frequencies. And the data output would have to be paused while the edge-alignment process takes place.
I guess some of you here could do this (FPGAs may be an option here?) but it admittedly is beyond me.
I may possibly also have observed another phenomenon related to reclocking that I cannot explain (maybe Marcel can - or could it be a well-known phenomenon?) and that is:
When I measure the noise on the VCC pin of the reclocking FF with a spectrum analyzer, this noise seems to be oddly "mixed" or "multiplied" with the sampling frequency. That is when the clock signal being reclocked is e.g. 2.8 MHz (DSD64) - and the reclocking reference clock is 45 MHz for the JLSounds board - it appears that the 2.8 MHz signal is "multiplied" into the noise of the reclocking FF VCC. That is there are noise spikes spaced 2.8 MHz apart on the VCC pin ... If the clock signal being reclocked is 11.2 MHz the VCC noise spikes are spaced 11.2 MHz apart, etc. ...
At first I thought this would be an error but I have checked the result some times and it does look as if this is what happens ... As I wrote I cannot explain why this may be so, but at least from my perspective it makes designing the decoupling of the FF VCC supply more tricky. And likely also predicting the phase noise performance of the reclocking setup at different frequency combinations becomes less straightforward ... (?)
So, with the above in mind, I have somewhat put development of a more "advanced" reclocking board on hold. Instead I tend to align the relevant edges in the DSD DAC itself (sort of what Marcel does in his RTZ DAC).
Cheers, Jesper
I have been thinking about this and I am not sure I can add that much to the discussion other than saying that IMHO what would be most interesting would be if it were possible to e.g. use a 5.6 MHz oscillator with e.g. the JLSounds board and then be able to align the BCLK & LRCK edges output from the JLSounds board. In this way such a setup could be used in most all cases and for example also with an R2R DAC with the full benefit of the low phase noise of the lower frequency oscillator.
However, as far as I can see this would require a "continuous" adjustment of edges to comply with all the various sampling frequencies when those are shifted.
I reckon it could be done maybe e.g. with a double PLL - maybe something like this:
- The first PLL is the one in the clock multiplier which locks onto the incoming lower frequency reference clock. This reference clock is then multiplied to 45/49 MHz and output to the USB board in question (e.g. the JLSounds board) which I guess also has a PLL ... ?
- The second PLL is a (much) slower PLL which slowly aligns the desired edges without causing the neither the JLSounds board or the multiplier PLL to detect a "clock malfunction" and therefore terminate the data transmission.
This would have to work for all relevant frequencies of reference clock(s) and sampling frequencies. And the data output would have to be paused while the edge-alignment process takes place.
I guess some of you here could do this (FPGAs may be an option here?) but it admittedly is beyond me.
I may possibly also have observed another phenomenon related to reclocking that I cannot explain (maybe Marcel can - or could it be a well-known phenomenon?) and that is:
When I measure the noise on the VCC pin of the reclocking FF with a spectrum analyzer, this noise seems to be oddly "mixed" or "multiplied" with the sampling frequency. That is when the clock signal being reclocked is e.g. 2.8 MHz (DSD64) - and the reclocking reference clock is 45 MHz for the JLSounds board - it appears that the 2.8 MHz signal is "multiplied" into the noise of the reclocking FF VCC. That is there are noise spikes spaced 2.8 MHz apart on the VCC pin ... If the clock signal being reclocked is 11.2 MHz the VCC noise spikes are spaced 11.2 MHz apart, etc. ...
At first I thought this would be an error but I have checked the result some times and it does look as if this is what happens ... As I wrote I cannot explain why this may be so, but at least from my perspective it makes designing the decoupling of the FF VCC supply more tricky. And likely also predicting the phase noise performance of the reclocking setup at different frequency combinations becomes less straightforward ... (?)
So, with the above in mind, I have somewhat put development of a more "advanced" reclocking board on hold. Instead I tend to align the relevant edges in the DSD DAC itself (sort of what Marcel does in his RTZ DAC).
Cheers, Jesper
Hi Jesper,
Regarding the RF spectrum analyzer, it is SDR type? If so, does it have an anti-alias filter (the low cost ones often don't)? If no anti-alias filter then it could be showing a spectrum which is not entirely real.
Regarding reclocking schemes, the lowest phase noise crystals for audio are at around 5/6MHz. If using Andrea sine wave oscillators, the maximum number of doublers is two, so you can make pretty low phase noise clock signals up to 22/24MHz. Above that you would need a PLL to get 45/49MHz.
The next question is how do you want to use the clocks (which depends on how the R2R dac is clocked; is it primarily by LRCK?). To reclock you need a clock signal at no less than twice the frequency of the signal you want to reclock.
You may also want to know what audio sample rate the USB board is playing, which you can get from looking at its F0-F3 status signals (JL Sounds may call them A0-A3).
In terms of typical reclocking there should be no need to align clock edges, as they are going to come out aligned with the reclocker unless the edges of reclock signal and the signals to be reclocked don't meet the setup and hold times of the D-filp flops used. That process basically samples the input clocks a regular points in time defined by the reclocker signal. Since the USB board and 45/49MHz PLL signal that drives it tends to have a constant latency once the PLL settles, then we only need to make sure we don't have edge timing collisions as described above. Beyond that there should be no need to align edges, as reclocking does that automatically (at least so long as the dac will be driven by reclocked signals).
OTOH, if the dac is to be driven by reclocker signal itself, then that is where there could be an alignment problem. In that case the reclocker signal will also serve as LRCK (presumably) so the BCLK and DATA signals would need to be aligned with it. However, we should also end up with an LRCK signal from the USB board. The time between the USB board LRCK edges and the reclocker edges will tell us how much delay we need to add the the BCLK and data signal to bring them into alignment with the reclocker signal we wish to use to replace the USB board LRCK signal.
There are various ways to measure that time difference and introduce suitable delays into BCLK and DATA signals (either before or after reclocking) such that the overall I2S signal dac timing requirements are met. But first we need to know how much misalignment of LRCK relative to BCLK and DATA signals the dac can tolerate and still operate normally. Then we can look into designing some delay circuitry and see what we can figure out.
Also, if we want to be able to play higher sample rates too, always with minimum phase noise, then we might need to spilt the output of the oscillators and doublers at each stage so we can produce low phase noise clocks at multiple frequencies. For that we would have to figure out how to spilt clock and doubler outputs without losing too much clock signal power at each step in the process. It would be another design problem to look into.
Those are my initial thoughts anyway.
Cheers,
Mark
Regarding the RF spectrum analyzer, it is SDR type? If so, does it have an anti-alias filter (the low cost ones often don't)? If no anti-alias filter then it could be showing a spectrum which is not entirely real.
Regarding reclocking schemes, the lowest phase noise crystals for audio are at around 5/6MHz. If using Andrea sine wave oscillators, the maximum number of doublers is two, so you can make pretty low phase noise clock signals up to 22/24MHz. Above that you would need a PLL to get 45/49MHz.
The next question is how do you want to use the clocks (which depends on how the R2R dac is clocked; is it primarily by LRCK?). To reclock you need a clock signal at no less than twice the frequency of the signal you want to reclock.
You may also want to know what audio sample rate the USB board is playing, which you can get from looking at its F0-F3 status signals (JL Sounds may call them A0-A3).
In terms of typical reclocking there should be no need to align clock edges, as they are going to come out aligned with the reclocker unless the edges of reclock signal and the signals to be reclocked don't meet the setup and hold times of the D-filp flops used. That process basically samples the input clocks a regular points in time defined by the reclocker signal. Since the USB board and 45/49MHz PLL signal that drives it tends to have a constant latency once the PLL settles, then we only need to make sure we don't have edge timing collisions as described above. Beyond that there should be no need to align edges, as reclocking does that automatically (at least so long as the dac will be driven by reclocked signals).
OTOH, if the dac is to be driven by reclocker signal itself, then that is where there could be an alignment problem. In that case the reclocker signal will also serve as LRCK (presumably) so the BCLK and DATA signals would need to be aligned with it. However, we should also end up with an LRCK signal from the USB board. The time between the USB board LRCK edges and the reclocker edges will tell us how much delay we need to add the the BCLK and data signal to bring them into alignment with the reclocker signal we wish to use to replace the USB board LRCK signal.
There are various ways to measure that time difference and introduce suitable delays into BCLK and DATA signals (either before or after reclocking) such that the overall I2S signal dac timing requirements are met. But first we need to know how much misalignment of LRCK relative to BCLK and DATA signals the dac can tolerate and still operate normally. Then we can look into designing some delay circuitry and see what we can figure out.
Also, if we want to be able to play higher sample rates too, always with minimum phase noise, then we might need to spilt the output of the oscillators and doublers at each stage so we can produce low phase noise clocks at multiple frequencies. For that we would have to figure out how to spilt clock and doubler outputs without losing too much clock signal power at each step in the process. It would be another design problem to look into.
Those are my initial thoughts anyway.
Cheers,
Mark
Last edited:
Requirements for reclocking are different depending on the DAC chip but also on the data format. Edge alignment is typically needed for DSD but, as discussed before, not for I2S. E.g. as I2SoverUSB supposedly works with AKM dacs up to 768k/DSD512 it most probably uses different reclocking schemes in the onboard CPLD for I2S and DSD. STM32 MCUs which I'm using do not align generated BCK and WS edges in I2S master mode but leave minimum 6ns between the edges.
As said DS dacs do not need reclocking of I2S signals. Also in dacs using separate filter ICs (e.g. PMD100) the reclocking should be done on the I2S signals generated by the filter. So for best results the reclocking should be implemented case-by-case at the dac.
As said DS dacs do not need reclocking of I2S signals. Also in dacs using separate filter ICs (e.g. PMD100) the reclocking should be done on the I2S signals generated by the filter. So for best results the reclocking should be implemented case-by-case at the dac.