The CS8416 uses an external loop filter for the PLL. You could tweak its bandwidth by changing the filter components. I haven't read far enough into the data sheet to tell whether it provides enough information to properly design the loop filter though.
Tom
Tom
"Jitter cleaner" is just a long-form way of writing PLL. 😉 The LMK04000 uses two PLLs in series to really clean up the jitter. I have a few circuits in that part. 🙂 That's not to say that a cascaded PLL is the only way to clean up jitter, though. The Skyworks part looks intriguing. Thanks for mentioning that.
Tom
Tom
👍!
A few years ago I hesitated between dual-PLL and ASRC for my DAC project. Went with ASRC because I got a few free samples from AKM.
Cool. I'd imagine you could use the ASRC as a FIFO re-clocker as well. You don't have to make it change the sample rate. If you feed it a clean clock the output should be clean. "Should"... 🙂 Life is fun when the phase noise analyzer gets involved.
Which AKM did you go with?
Tom
Which AKM did you go with?
Tom
the DAC has AK4493 as converter, AK4137 as ASRC, taking I2S feed from WM8805, local MCLK by si570, all hooked up through an I2C mastered by an Arduino nano. So far the ASRC converts whatever sample rate into 195K. And yeah, it would be a few extra lines of code and it would be able to follow the incoming sample rate. But I guess that wouldn't be like FIFO-ish bit-precise, instead it would still do its "convert" thing, into a new clock domain.
Both the LMK04000 and SI5317 look interesting. Thanks for sharing.
Tom's statement is absolutely correct.
You want MCLK for a DAC/ADC to have good low frequency jitter. Both of these devices appear capable of very good low frequency jitter performance.
Al
Tom's statement is absolutely correct.
You want MCLK for a DAC/ADC to have good low frequency jitter. Both of these devices appear capable of very good low frequency jitter performance.
Al
The LMK04800 and possibly the LMK03328 could be interesting as well. Or LMX2581 if you only need a single PLL. All of them have really high-end VCOs in them.
Tom
Tom
Hi all,
since spdif->i2s retains bit perfect output (with some jitter) it would be enough to use i2s FIFO, reclocked by a precise clock.
e.g. https://www.diyaudio.com/community/threads/re-clocking-i2s-simple-version.396381/
since spdif->i2s retains bit perfect output (with some jitter) it would be enough to use i2s FIFO, reclocked by a precise clock.
e.g. https://www.diyaudio.com/community/threads/re-clocking-i2s-simple-version.396381/
Unicycle's question has been done but in many ways it is impractical.
1. You basically need to delay everything into a fairly large buffer. This is because your local "perfect" clock will always be slower or faster that the source.
2. The buffer holds perhaps several seconds of samples. If you start at the middle of the buffer, you will slowly move to the one end of the buffer depending on whether you local clock is faster or slower than the source.
3. Usually, this method resyncs between tracks. Bigger buffers with even more latency would store a whole album.
Obviously, this method is useless if video syncing is desired.
Fractional N PLL performance like the WM8805 is going to be able to achieve its 50pS probably without the incoming jitter affecting the result assuming it locks in the first place (data is correct). I don't thing 50pS jitter performance is good enough for SOA converters operating in the 123-130 dB range, but it is much better than typical S/PDIF at the receiver input
A good ASRC will tend to be as good as the local clock source if the measurement period is long. This is true in an Analog Devices' DSP and most other ASRC devices. It is sometimes crappy in embedded products like wireless converters. Once you encode jitter with a bad ASRC it is permanent. Jitter matters until it is sufficiently small. It relates directly to aperture uncertainty. Results with a good ASRC will be in the small ps range if the local clock is good. Jitter performance is easily messed up by your PCB layout and buffering, so the local clock by itself does not actually determine performance (but it certainly contributes).
Al
1. You basically need to delay everything into a fairly large buffer. This is because your local "perfect" clock will always be slower or faster that the source.
2. The buffer holds perhaps several seconds of samples. If you start at the middle of the buffer, you will slowly move to the one end of the buffer depending on whether you local clock is faster or slower than the source.
3. Usually, this method resyncs between tracks. Bigger buffers with even more latency would store a whole album.
Obviously, this method is useless if video syncing is desired.
Fractional N PLL performance like the WM8805 is going to be able to achieve its 50pS probably without the incoming jitter affecting the result assuming it locks in the first place (data is correct). I don't thing 50pS jitter performance is good enough for SOA converters operating in the 123-130 dB range, but it is much better than typical S/PDIF at the receiver input
A good ASRC will tend to be as good as the local clock source if the measurement period is long. This is true in an Analog Devices' DSP and most other ASRC devices. It is sometimes crappy in embedded products like wireless converters. Once you encode jitter with a bad ASRC it is permanent. Jitter matters until it is sufficiently small. It relates directly to aperture uncertainty. Results with a good ASRC will be in the small ps range if the local clock is good. Jitter performance is easily messed up by your PCB layout and buffering, so the local clock by itself does not actually determine performance (but it certainly contributes).
Al
Thank you danville for the insight.
The difference between two clocks shouldn't be that big maybe <10ppm,
To avoid bit slip and FPGA I found this device, dual ended FIFO, 5usd, feeding and consuming clock can be different, up to 40Mhz
https://www.ti.com/product/SN74ALVC7804
512 clock depth, 18channels
Maybe it's the Holy Grail?
What about cascading two SPDIF receivers?
First stage will have 50ps jitter, second stage should have easier time to recover the original clock.
The difference between two clocks shouldn't be that big maybe <10ppm,
To avoid bit slip and FPGA I found this device, dual ended FIFO, 5usd, feeding and consuming clock can be different, up to 40Mhz
https://www.ti.com/product/SN74ALVC7804
512 clock depth, 18channels
Maybe it's the Holy Grail?
What about cascading two SPDIF receivers?
First stage will have 50ps jitter, second stage should have easier time to recover the original clock.