So just to clarify, the CS8420 is evil because of it's weird behaviour / control glitches / resetting not because it sounds really bad?
I'm just checking because things like the behringer DCX. DEQ, SRC 2496 use it and they seem to 'work'. Is there any other reason why one should avoid gear using this chip?
Please don't come back with usefull information like "all OS Dacs suck" or "Behringer copies other peoples designs", I'm talking about sound compared to other simlar Input receiver / SRC chips!
I'm just checking because things like the behringer DCX. DEQ, SRC 2496 use it and they seem to 'work'. Is there any other reason why one should avoid gear using this chip?
Please don't come back with usefull information like "all OS Dacs suck" or "Behringer copies other peoples designs", I'm talking about sound compared to other simlar Input receiver / SRC chips!
The CS8420 sounds great, mine went into the so called muffled mode once it the 2 years that i've had it, what i do now is, to turn on the dac first, then the transport. the time it went into muffled mode, I had the transport on first, then I turned the dac on. Like I said this has only happened once, and I cannot get it to do it again.
Cheers George
Cheers George
CS8420 evil
thejohn, georgehifi:
Ja well, no fine. You about summed it up - there's absolutely nothing wrong with the sound performance of the CS8420, when it's working properly, that is. On paper it's been outclassed by newer developments but it's arguable whether the specmanship points scored by the (eg CS8421, AD1896, SRC1492 etc) translate into a sonic improvement over the CS8420.
And the accumulated wisdom of workarounds for CS8420 quirks in a thread such as this is by now so comprehensive that it should be possible to get a reasonably reliable CS8420 implementation.
BUT - while it may be 'acceptable' for an 8420 in your home or mine to once every six weeks or six months go into 'muffled mode', 'mute mode' or even 'popcorn mode', none of this is acceptable for equipment sold to the broadcast industry. If their top billed 'Watch-the-zucchinis-in-the-House' reality TV show gets a 0.5s dropout in audio, they can lose ££££ in advertising revenue and then they come hissing at your door like angry snakes.
Cheers
John
thejohn, georgehifi:
Ja well, no fine. You about summed it up - there's absolutely nothing wrong with the sound performance of the CS8420, when it's working properly, that is. On paper it's been outclassed by newer developments but it's arguable whether the specmanship points scored by the (eg CS8421, AD1896, SRC1492 etc) translate into a sonic improvement over the CS8420.
And the accumulated wisdom of workarounds for CS8420 quirks in a thread such as this is by now so comprehensive that it should be possible to get a reasonably reliable CS8420 implementation.
BUT - while it may be 'acceptable' for an 8420 in your home or mine to once every six weeks or six months go into 'muffled mode', 'mute mode' or even 'popcorn mode', none of this is acceptable for equipment sold to the broadcast industry. If their top billed 'Watch-the-zucchinis-in-the-House' reality TV show gets a 0.5s dropout in audio, they can lose ££££ in advertising revenue and then they come hissing at your door like angry snakes.
Cheers
John
JohnW said:"Is the CS8420 really that bad"
YES - Just Terrible! Completely destroys the audio performance / sound stage.
Also the PLL on the integral SPDIF Rx has a Bi-Modal phase noise distribution. This means instead of having a single clean narrow clock carrier (single frequency). There are two carriers (two frequencies) close together – poor PLL design.
On a spectrum analyzer sweep, the profile of this distribution depicts the wrong kind silicon……. (At least in this instants)
John
I have to agree with John. I found the same result with the CS8427. The CS8414 is a lot better and I'd use that in preference any day to the CS8427. Now TI has dropped their PLL-based receivers you have to go with the evils of SRCs.... or hang on in there for a newcomer.
CS8420 et al
Hi Skippy
It's not clear which John you agree with! JohnW is particular about performance issues that are several orders beyond what many of us worry about, and is a true perfectionist. It's his prerogative.
But whatever your view, if you feel uncomfortable using a CS8420 then the safest option is a CS8416 RX followed by an AD1896/SRC4192 SRC. I've experienced 'funnies' with the CS8414 in the past, so I would stay away from it. Also, there are future availability issues for the '14.
Crystal (Cirrus) claim the most amazing performance on their new CS8421 standalone SRC chip, which could also be used with a CS8416. But for many of us who have cursed the 8420 at times, using the CS8421 in a new design would involve an untenable leap of faith.
But there is another more interesting option which I haven't yet explored and am very keen to do so: Both Xilinx and Altera now claim to have open cores (ie free code) available to implement both AES/SPDIF receivers and SRCs in their FPGAs. From my discussions with these companies' FAEs it would appear that the Xilinx solution has the advantage of 'scalable performance', depending on how much FPGA processing logic you are prepared to throw at it. But it's my understanding that it's a two channel (stereo) solution and to make multiple 2xchannels one would involve replicating the whole design.
On the other hand the Altera solution is inherently a multichannel multiplexed system but the dynamic range performance is only about CS8420 level. (115-120dB) It's unlikely that either of these core solutions would be operable on each other's platforms because they will almost certainly be tailored for optimal use of the particular DSP block structure in the Xilinx/Altera FPGA.
Obviously the cost of an FPGA solution would only be justifiable if you had other processing to do - which many of us do - but I believe it's the way of the future.
Is there anybody out there who's tried these FPGA receivers and SRC's and could provide some feedback?
Salut
John
Hi Skippy
It's not clear which John you agree with! JohnW is particular about performance issues that are several orders beyond what many of us worry about, and is a true perfectionist. It's his prerogative.
But whatever your view, if you feel uncomfortable using a CS8420 then the safest option is a CS8416 RX followed by an AD1896/SRC4192 SRC. I've experienced 'funnies' with the CS8414 in the past, so I would stay away from it. Also, there are future availability issues for the '14.
Crystal (Cirrus) claim the most amazing performance on their new CS8421 standalone SRC chip, which could also be used with a CS8416. But for many of us who have cursed the 8420 at times, using the CS8421 in a new design would involve an untenable leap of faith.
But there is another more interesting option which I haven't yet explored and am very keen to do so: Both Xilinx and Altera now claim to have open cores (ie free code) available to implement both AES/SPDIF receivers and SRCs in their FPGAs. From my discussions with these companies' FAEs it would appear that the Xilinx solution has the advantage of 'scalable performance', depending on how much FPGA processing logic you are prepared to throw at it. But it's my understanding that it's a two channel (stereo) solution and to make multiple 2xchannels one would involve replicating the whole design.
On the other hand the Altera solution is inherently a multichannel multiplexed system but the dynamic range performance is only about CS8420 level. (115-120dB) It's unlikely that either of these core solutions would be operable on each other's platforms because they will almost certainly be tailored for optimal use of the particular DSP block structure in the Xilinx/Altera FPGA.
Obviously the cost of an FPGA solution would only be justifiable if you had other processing to do - which many of us do - but I believe it's the way of the future.
Is there anybody out there who's tried these FPGA receivers and SRC's and could provide some feedback?
Salut
John
John Hope - the quotation insert I used (first time ever!) fortunately did show JohnW, so I hope that was clear.
My problem and JohnW's is that the 8427, and to a lesser extent the 8414, show characteristics of being unstable. They just don't stay properly locked. You can see two humps in the jitter spectrum. The 8427 went through several revisions too, but none of these fixed this problem.
I would also say that if you don't need SRC, don't use it i.e. if you don't want to go between 44.1k and 48k, then don't. SRC from 44.1 to 44.1, where the two frequencies are close, is a nasty process.
The jitter specification of FPGAs has never been very good, but I have used them in the audio band for Class D modulators successfully. Not commercially viable on cost grounds, but great fun for DIY.
Better still use a decent PLL, because that is really what you want to do. There's a very good one in the WM8777. All we need now is for Wolfson to do a standalone SPDIF chip.
My problem and JohnW's is that the 8427, and to a lesser extent the 8414, show characteristics of being unstable. They just don't stay properly locked. You can see two humps in the jitter spectrum. The 8427 went through several revisions too, but none of these fixed this problem.
I would also say that if you don't need SRC, don't use it i.e. if you don't want to go between 44.1k and 48k, then don't. SRC from 44.1 to 44.1, where the two frequencies are close, is a nasty process.
The jitter specification of FPGAs has never been very good, but I have used them in the audio band for Class D modulators successfully. Not commercially viable on cost grounds, but great fun for DIY.
Better still use a decent PLL, because that is really what you want to do. There's a very good one in the WM8777. All we need now is for Wolfson to do a standalone SPDIF chip.
There was a standalone SPDIF receiver made by Wolfson, the WM8803. At least it was presented in the news, for example here:
http://www.electronicstalk.com/news/wol/wol148.html
Unfortunately, the WM8803 is not listed on Wolfsons website anymore.
Producing SPDIF receivers seems to be a tricky business
Regards,
Florian
Re: CS8420 et al
Hi John,
Do you have any links to the "free" Xilinx SRC IP you mentioned, I use the SPDIF receiver IP cores (with external VCXO) with good results, but still need an ASRC for non standard sampling rates / or units with poor PPM clocks.
I agree with Skippy, the best ASRC is no ASRC - with a short depth FIFO & a VCXO theres really no need for an ASRC for jitter attenuation.
Skippy,
seems like you have some experance of Class D modulator designs in FPGA - I'm always on the lookout for good Modulator designers... give me a PM if your interested,
John
John Hope said:
Hi John,
Do you have any links to the "free" Xilinx SRC IP you mentioned, I use the SPDIF receiver IP cores (with external VCXO) with good results, but still need an ASRC for non standard sampling rates / or units with poor PPM clocks.
I agree with Skippy, the best ASRC is no ASRC - with a short depth FIFO & a VCXO theres really no need for an ASRC for jitter attenuation.
Skippy,
seems like you have some experance of Class D modulator designs in FPGA - I'm always on the lookout for good Modulator designers... give me a PM if your interested,
John
Hi John
My info on the Xilinx and Altera cores comes from these companies' AE's at the IBC show in Amsterdam this September. Both companies indicated the release of these cores was imminent. But as you must know, 90% of anything advertised at a show doesn't exist yet and is either VapourWare or FishingWare.
At this time the only info I could find on either site was a Waffle-O press release from Altera. The Altera AE who described their system to me is Oliver Cousin, and I believe he's based up the road from us in their White Palace at High Wycombe. You may be able to get beta versions of their system for evaluation. His e-mail is: ocousin@altera.com
The Xilinx FAEs who described their system are:
Matt.Klein@xilinx.com
Gregg.hawkes@xilinx.com
Regards
John H
My info on the Xilinx and Altera cores comes from these companies' AE's at the IBC show in Amsterdam this September. Both companies indicated the release of these cores was imminent. But as you must know, 90% of anything advertised at a show doesn't exist yet and is either VapourWare or FishingWare.
At this time the only info I could find on either site was a Waffle-O press release from Altera. The Altera AE who described their system to me is Oliver Cousin, and I believe he's based up the road from us in their White Palace at High Wycombe. You may be able to get beta versions of their system for evaluation. His e-mail is: ocousin@altera.com
The Xilinx FAEs who described their system are:
Matt.Klein@xilinx.com
Gregg.hawkes@xilinx.com
Regards
John H
Many, many thanks for this thread...
...specially to georgehifi, gmarsh and jwb.
Here's my sad story:
I run a Monarchy Audio DIP upsampler, wich I think has a CS8420, that feeds an M-audio superDAC(AK4393 DAC), heavily moded. Just when I reached intoxicatingly good sound, an annoying HF distortion ocurred wich I attributed to my last digital PS mod (newb
). I tried swaping caps, wiring, regs, screens, etc... and it wouldn't go, until yesterday when I found this thread and turn-on the DIP first
How simple
I would make the same with CS8414 based NONOS-DAC, just to see...
Again, I'm indebted to all
Mauricio
...specially to georgehifi, gmarsh and jwb.
Here's my sad story:
I run a Monarchy Audio DIP upsampler, wich I think has a CS8420, that feeds an M-audio superDAC(AK4393 DAC), heavily moded. Just when I reached intoxicatingly good sound, an annoying HF distortion ocurred wich I attributed to my last digital PS mod (newb
). I tried swaping caps, wiring, regs, screens, etc... and it wouldn't go, until yesterday when I found this thread and turn-on the DIP first How simple
I would make the same with CS8414 based NONOS-DAC, just to see...
Again, I'm indebted to all
Mauricio
In this case it'll be difficult to use a VCXO which has a lot of very low frequency (thermal) phase noise. In that case you need a OCVCXO. But that's $$$$ stuff.
To me a lot of that FIFO related jitter reduction is only marketing stuff because it's such a decriptive explanation. Feeding that crappy CS8416 with an also crappy low cost spdif source does not show enough phase noise that the sampling data and clocks can't be reclocked with a simple D-FF.
Bocka,
While you are correct in stating that only an Ovenised type XO can achieve “absolute” clock accuracy at LF, it’s important to consider that with digital audio we do not require absolute clock accuracy – but a clock that is free from CORRELATED artifacts.
When locking to real world signal sources, an Ovenised XO in the slave device is a waste of time, as the Slave device clock must ultimately track the Master clock in the longer term, if a reasonably small FIFO is to be used - I normal use a 20 Bit FIFO to reduce total system group delay, while insuring “Lip synch” in AV systems.
At a sampling frequency of 44.1 KHz, 22 Hz comes out as a magic number – system Phase Noise plots always show artifacts at 22Hz (I’ve never investigated which Clocks / Data beat to generate this component) (also 16.5Hz and 33Hz with DVD Audio). To adequately attenuate this (and other LF Phase noise components) requires a “PLL” type circuit that has sub Hz performance. Now designing PLL circuits with Sub Hz performance is a sure way to rapid hair loss – the simplest (and best) solution is to use a bit of logic, a short depth FIFO & a DAC controlled VCO.
With Digital Audio, a clock free from Correlated artifacts is King! – A small amount of drift between the Master and Slave clocks helps to broaden / randomize any “side-bands” in the “PLL” loop, so in fact the use of an Ovenised type VCXO in the slave device would be detrimental – small amounts of random LF clock drift is beneficial.
John
While you are correct in stating that only an Ovenised type XO can achieve “absolute” clock accuracy at LF, it’s important to consider that with digital audio we do not require absolute clock accuracy – but a clock that is free from CORRELATED artifacts.
When locking to real world signal sources, an Ovenised XO in the slave device is a waste of time, as the Slave device clock must ultimately track the Master clock in the longer term, if a reasonably small FIFO is to be used - I normal use a 20 Bit FIFO to reduce total system group delay, while insuring “Lip synch” in AV systems.
At a sampling frequency of 44.1 KHz, 22 Hz comes out as a magic number – system Phase Noise plots always show artifacts at 22Hz (I’ve never investigated which Clocks / Data beat to generate this component) (also 16.5Hz and 33Hz with DVD Audio). To adequately attenuate this (and other LF Phase noise components) requires a “PLL” type circuit that has sub Hz performance. Now designing PLL circuits with Sub Hz performance is a sure way to rapid hair loss – the simplest (and best) solution is to use a bit of logic, a short depth FIFO & a DAC controlled VCO.
With Digital Audio, a clock free from Correlated artifacts is King! – A small amount of drift between the Master and Slave clocks helps to broaden / randomize any “side-bands” in the “PLL” loop, so in fact the use of an Ovenised type VCXO in the slave device would be detrimental – small amounts of random LF clock drift is beneficial.
John
You're half right... the jitter which comes out of a CS8416 is extremely low - It's nowhere near the half-of-UI phase noise that would theoretically break D-flip-flop reclocking. Using an oscilloscope (not a phase noise measurement instrument but a good "will this system even work?" instrument) the 8416's RMCK output is indistinguishable from a good oscillator.bocka said:
But this only works if the reclocking clock is frequency and phase locked to the data being reclocked. Since this is coming from a VCXO+PLL with as low a bandwidth as possible, a fast enough drift (warmup?) occuring in either the VCXO or the original source could push the reclocking clock's phase off enough to break your reclocker. The lower your VCXO+PLL bandwidth is, the worse this becomes.
Adding a FIFO lets you tolerate much more frequency drift, which lets you push the PLL bandwidth lower offering better jitter rejection.
Marketing? nah, it makes sense.
Hi gmarsh,
I do not agree with you. Using a scope is not the right measurement intrument (at least without additional hardware) for this. RMCK jitter or phase noise is extremely high (in the 1..2ns pk,pk range).
How low this bandwith has to be? I designed a board with 3Hz bandwith. The VCXO input voltage does not vary in a measurable way (less than 10mV for a 3.3V input range over a 10s period). The PLL / reclocking stage does not drop data, if I could I'd lowering the bandwidth further, but this will not fit into my PLD anymore.
To me there is really not need to implement a reclocking stage with a FIFO. If a so-called 1-bit FIFO (yes, a single D-FF) does not run empty, why implement more stages? Yes it could tolerate more drift, but also sources like a DVD or CD transport does not show this drift in reality.
On the other side a very low bandwith results also in long locking times. Going down to about 1Hz seems nevertheless a good practical approch.
bocka said:
I've seen nowhere near 1-2nS of jitter on a CS8416 output. But even compared to the worst case RMCK frequency - RMCK, 256Fs, 192KHz which is 16.3nS, it's still acceptable for reclocking.
I don't disagree that a 1-bit FIFO, with your existing PLL/VCXO design, has worked great with every DVD/CD player you've hooked up to it. But if you plan to form a company around your product and market/sell it to the public, you'll want to be comfortable that it works with the worst imaginable CD/DVD players out there. A FIFO, though unnecessary for most things, provides a good "safety net".
It's entirely possible that someone's got an esoteric CD player with a completely **** power supply feeding unstable crystal circuit that's producing all sorts of low frequency wobble, with the SPDIF output finally asynchronously reclocked
And if Murphy's Law holds true, they'll be the person that's reviewing your product for a magazine...I'd spend some time with an Audio Precision SYS-2522 or 2722 and deliberately feed jitter of various amplitudes and frequencies into your design. I've done this with things I've designed, and you can learn quite a bit from it.
JohnW said:
bocka said:
Well, I'm just trying to understand, so don't see here anything more than a naive question, and correct me if I'm wrong.
From what I've understood, jitter is a phase noise, and translates in time domain to an uncertainty on the transition times on signals. Right ?
Now, the simple path. Imagine a free running clock with a very low jitter (the Holy Grail)
. As it's a standalone clock, can I assume that it is decorrelated from the rest of the signal chain of a DAC ? So its -low- jitter should also be decorrelated, or am I misreading the term "decorrelated" ? Of course, I'm assuming here that it has a perfectly clean power supply that removes all the possible artifacts of surrounding supply lines and add nothing to the rails... Now run this clock at twice the highest frequency of digital signals (the bitclock in a DAC, for instance), and use it to reclock all the signals with a simple D flip-flop, as Bocka does. Wouldn't it be sufficient to "replace" the jitter on the digital signals by the lower jitter of our clock (plus the D flip flop induced jitter) ? Again, I'm assuming that the Dff's power supply is as clean as possible.Am I saying something stupid ? Or is this scheme improvable ?
And while we're at it, a question for JohnW : did you try the discrete oscillator of this old post ? Do you have results in terms of jitter, or did you chose another design ?
Thanks
I think "un-correlated" might be a better choice of words.
Yes, the clock should have jitter that is only a product of random noise. Problem is...........the crap on the supply rail that feeds it is not.
There are some other threads raging about jitter, and dither, and what group of experts is right. Try the "listen to the rails" suggestion in one of them. Especially if there is a SPDIF RX chip involved. I would like someone to tell us what they hear.
Jocko
Yes, the clock should have jitter that is only a product of random noise. Problem is...........the crap on the supply rail that feeds it is not.
There are some other threads raging about jitter, and dither, and what group of experts is right. Try the "listen to the rails" suggestion in one of them. Especially if there is a SPDIF RX chip involved. I would like someone to tell us what they hear.
Jocko
Thanks Jocko,
Well, english not being my native language, I must admit the difference between "de"correlated and "un"correlated is still hard to handle My poor french language only has "decorrelated", which would better mean "not correlated". But it's only semantics, and if I understand, we should stick to a jitter that is not correlated in any way to the surrounding phenomena.
And yes, I'm more than aware that the power supply noises other than purely random noise (thermal or whatever) are obviously correlated to what happens on the board.
But I still have no answer to my question about D flipflop reclocking... Wouldn't it be sufficient to clean jittery signals, againg assuming a nice power supply... What are the flaws here... Or what kind of advantage brings a higher order reclocking scheme, as a FIFO, in the same supply configuration (clean one). Or in a noisy supply configuration, has the latter approach an advantage ?
Thanks
Well, english not being my native language, I must admit the difference between "de"correlated and "un"correlated is still hard to handle
My poor french language only has "decorrelated", which would better mean "not correlated". But it's only semantics, and if I understand, we should stick to a jitter that is not correlated in any way to the surrounding phenomena. And yes, I'm more than aware that the power supply noises other than purely random noise (thermal or whatever) are obviously correlated to what happens on the board.
But I still have no answer to my question about D flipflop reclocking... Wouldn't it be sufficient to clean jittery signals, againg assuming a nice power supply... What are the flaws here... Or what kind of advantage brings a higher order reclocking scheme, as a FIFO, in the same supply configuration (clean one). Or in a noisy supply configuration, has the latter approach an advantage ?
Thanks
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.