I've been reading a lot about DAC's lately. I am planning on building a DAC from Elektor boasting CS8420/8414, DF1704 and two PCM1704.
I was going to use the 8420 upsampler, but after reading this forum I am somewhat reluctant to use it.
I have following two questions:
- Is there anybody who has tried the CS8420 in this particular DAC?
I could imagine that its (subjective and objective) performance is depending on the particular implementation. For example Elektor use Goudreau's triplets for local decoupling! I would be very interested in hearing experiences from people who started with CD8414 and later upgraded to CS8420.
- Are there any other high-end DAC designs available?
NONOS DACs seem to get a lot of attention on this forum. I suspect however that the reason for their popularity is mainly induced by their simplicity and low cost.
I am looking for a available design with state of the art technology.
Thanks,
ABo
I was going to use the 8420 upsampler, but after reading this forum I am somewhat reluctant to use it.
I have following two questions:
- Is there anybody who has tried the CS8420 in this particular DAC?
I could imagine that its (subjective and objective) performance is depending on the particular implementation. For example Elektor use Goudreau's triplets for local decoupling! I would be very interested in hearing experiences from people who started with CD8414 and later upgraded to CS8420.
- Are there any other high-end DAC designs available?
NONOS DACs seem to get a lot of attention on this forum. I suspect however that the reason for their popularity is mainly induced by their simplicity and low cost.
I am looking for a available design with state of the art technology.
Thanks,
ABo
Hi ABo, I believe the reason for NON-OS is also better sound. At least for me the first NON-OS experiment was a jaw-dropping experience. Personally I do not like upsamplers. I heard two of these made by Electrocompaniet and Musical Fidelity. I was not impressed. I feel the CS8414 is worse than the CS8412 for redbook CDs.
I've built a version of jwb's simple DAC that uses a CS8420, and I like the sound very much. However, I wouldn't recommend that chip because it has a bug (I believe in all revisions) that necessitates a workaround, meaning extra complexity (see the latest datasheet for details). I used the workaround, but if you are starting a new DAC project you should consider another asynchronous sample rate converter.
You may also look around for the few DAC projects that slave the transport to the DAC clock. That seems the best theoretical solution, though ugly in practice due to the need of an additional interconnect.
Regarding the OS/non-OS, why not add a switch so you can toggle between the two modes and be able to do listening comparisons? Using a computer to drive the switch, you can use software such as abchr to perform a blind test by yourself.
You may also look around for the few DAC projects that slave the transport to the DAC clock. That seems the best theoretical solution, though ugly in practice due to the need of an additional interconnect.
Regarding the OS/non-OS, why not add a switch so you can toggle between the two modes and be able to do listening comparisons? Using a computer to drive the switch, you can use software such as abchr to perform a blind test by yourself.
Here.
But you already know this, as I see at least one post by you in that thread.
The MOSFETs have too much input capacitance, so I replaced the analog stage with a JFET buffer, and added a step attenuator for volume control, motorizing it so it can be remote controlled. In the digital section, I added a discrete logic reset circuit to catch bug-prone states of the CS8420. Latching relays for switching I/O connections, some extra logic for control and remote control, standby supply, and it turned out a nice project.
But you already know this, as I see at least one post by you in that thread.
The MOSFETs have too much input capacitance, so I replaced the analog stage with a JFET buffer, and added a step attenuator for volume control, motorizing it so it can be remote controlled. In the digital section, I added a discrete logic reset circuit to catch bug-prone states of the CS8420. Latching relays for switching I/O connections, some extra logic for control and remote control, standby supply, and it turned out a nice project.
"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
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 find the CS8420 was good enough for my "cheap" DAC. The bug is annoying, but you won't run into it if you never unplug the digital cable, and if you turn off the DAC before turning off the source.
That said the AD1896 is better, and the SRC4192 is better yet, and pin-compatible with the Analog part. However with these parts you'll need a separate DIR, for example CS8416.
That said the AD1896 is better, and the SRC4192 is better yet, and pin-compatible with the Analog part. However with these parts you'll need a separate DIR, for example CS8416.
ABO said:
http://httpd.chello.nl/~m.heijligers/DAChtml/dactop.htm
http://www.passlabs.com/downloads/old product/d1_servm.pdf
http://koti.mbnet.fi/siliconf/JukkaTolonen/projects/jt-dac_no.3/jt-dac_no.3.html
http://www.quadesl.com/dac.shtml - Tube DAC
http://www-s.ti.com/sc/psheets/sbau013/sbau013.pdf - DEM-DAI1704: Evaluation Fixture for the PCM1704, DF1704
The designs linked to above are all conceptually similar, in digital terms, to the Elektor dac when the ASRC is functioning as a receiver and though all but the PCM1704 EVB use dacs other than the PCM 1704, they can all be adapted with relative ease to use the PCM1704. The first two options also include a PLL/VCXO retiming circuit.
A possible contender http://www.audiocraftersguild.com/XD0/XD0_index.htm
A diy PCM 1798 Dac.http://www.diyaudio.com/forums/showthread.php?s=&threadid=38181&perpage=10&highlight=&pagenumber=3 - See post 29.
For quite a few dacs, http://www.diyaudio.de/html/projects.html
My rant on the CS8420...
If you disconnect the SPDIF input and reconnect the input a couple of times, it spits out garbage. The workaround (which requires a microcontroller) is to sense the lock detect output, and then reset the CS8420. Most of the time, this will make it put out good audio again, but not always - sometimes the output would be great after reconnection, but doing a reset would make the chip put out garbage.
I designed the 8420 into a board at work, then encountered this problem during reliability testing. And I had to throw out a bunch of boards because of it... The Crystal engineers were no help - they wanted me to remove a part from the board and send it to them to "evaluate"... sigh.
Nowadays I use a separate RS422 RX feeding a CS8416 (which doesn't seem to have any such problems) which feeds a separate SRC. Now that TI has tossed out their DIR170x parts, the Analog Devices RX/SRC is outdated and AKM stuff isn't easily available in North America, there's not much else to choose from...
If you disconnect the SPDIF input and reconnect the input a couple of times, it spits out garbage. The workaround (which requires a microcontroller) is to sense the lock detect output, and then reset the CS8420. Most of the time, this will make it put out good audio again, but not always - sometimes the output would be great after reconnection, but doing a reset would make the chip put out garbage.
I designed the 8420 into a board at work, then encountered this problem during reliability testing. And I had to throw out a bunch of boards because of it... The Crystal engineers were no help - they wanted me to remove a part from the board and send it to them to "evaluate"... sigh.
Nowadays I use a separate RS422 RX feeding a CS8416 (which doesn't seem to have any such problems) which feeds a separate SRC. Now that TI has tossed out their DIR170x parts, the Analog Devices RX/SRC is outdated and AKM stuff isn't easily available in North America, there's not much else to choose from...
Well I figure any ASRC that is calculating the clock ratio over at least 1000 samples is going to have excellent jitter rejections beginning at very low frequencies.
As for the SRC4192, TI claims better specs, and the part is more easily gotten (Digikey) and cheaper, and you have the option to interface it with your control logic (SRC4193), which you don't get on the AD1896. As for actual performance, I am totally unequipped for such an evaluation.
The new SHARC parts have three AD1896 cores integrated. Handy feature, that.
As for the SRC4192, TI claims better specs, and the part is more easily gotten (Digikey) and cheaper, and you have the option to interface it with your control logic (SRC4193), which you don't get on the AD1896. As for actual performance, I am totally unequipped for such an evaluation.
The new SHARC parts have three AD1896 cores integrated. Handy feature, that.
CS8420 worse than bad
Hi all
The CS8420 is really and truly EVIL. And it's at its absolute worst when used in I2C software control mode.
Apart from all the issues mentioned under this thread, I've found also that it can sometimes (1 time in 60 or so) wake up in a strange 'muffled' mode, where audio is passed but sounds like it's LPF'd at about 8kHz! Re-initialise the chip and it fixers itself.
Don't use this chip; as has been suggested, the AD1896/SRC4192 and CS8416 combo is far, far better and will not give you headaches!
Cheers
John Hope
Hi all
The CS8420 is really and truly EVIL. And it's at its absolute worst when used in I2C software control mode.
Apart from all the issues mentioned under this thread, I've found also that it can sometimes (1 time in 60 or so) wake up in a strange 'muffled' mode, where audio is passed but sounds like it's LPF'd at about 8kHz! Re-initialise the chip and it fixers itself.
Don't use this chip; as has been suggested, the AD1896/SRC4192 and CS8416 combo is far, far better and will not give you headaches!
Cheers
John Hope
Its not as bad as eveyone says, eventhough its all true.
Its main benefits for diy is the package, you can actually hardwire it if you want and a set of 0805 SMD ceramics will fit nicely between the ground and powersupply legs, can't get much closer then that.
For audio performance you absolutly need to be able to reset it every now and again.
I think if well implemented its probably more transparent then most dac chips or opamps.
It is sensitive to implementation, you need good decoupling, solid ground, a good clock close to the chip, separate low noise powersupply with individual regulation, a good spdif reciever curcuit etc.
I guess this is true for everything but I found it having a very different sonic signature with different implementations of the above.
If you can live with SSOP's then the others are better as discussed.
Its main benefits for diy is the package, you can actually hardwire it if you want and a set of 0805 SMD ceramics will fit nicely between the ground and powersupply legs, can't get much closer then that.
For audio performance you absolutly need to be able to reset it every now and again.
I think if well implemented its probably more transparent then most dac chips or opamps.
It is sensitive to implementation, you need good decoupling, solid ground, a good clock close to the chip, separate low noise powersupply with individual regulation, a good spdif reciever curcuit etc.
I guess this is true for everything but I found it having a very different sonic signature with different implementations of the above.
If you can live with SSOP's then the others are better as discussed.
CS8420 H/W vs S/W mode
Hi Guys
I have used the CS8420 in many different applications both for hobby use and for my designs at work, ever since the device was first released. I'm fully familiar with the hardware layout and decoupling requirements, as suggested by Cirrus and several diyAudio members. In this context I would like to add that I find a lot of problems can be eliminated by feeding the VCC of the CS8420 through a ferrite bead. Cirrus don't stress the importance of this FB enough; it should always be fitted.
There were some early CS8420 silicon revisions (B and C) which had serious bugs - admitted by Cirrus FAEs to myself and colleagues - for which there were no workarounds. Silicon of Rev D (about 2000 vintage) is the first reasonable one. If you're using earlier ones, get rid of them.
I've generally found the 8420 seems to work more reliably in hardware mode than in software mode. In software mode they can be really, really EVIL, necessitating elaborate workarounds. One thing I would say here is that clearing the RUN bit before making configuration/clock/dataflow changes, and then setting it again after making the changes AND waiting for all signals to be stable, is imperative. Cirrus do not stress this enough.
I've also used the CS8427, which is a CS8420 with no SRC, and have experienced no problems with this chip in hardware or software mode. The CS8427 is made in a different foundry to the CS8420 and I suspect uses newer technology
DIYer's are more likely to use the CS8420 in a fixed configuration in hardware mode and should not find it too much of a Black Dog. But I still really wouldn't recommend anyone use the 8420 in software mode for new designs. Why punish yourself?
Regards
John Hope
Hi Guys
I have used the CS8420 in many different applications both for hobby use and for my designs at work, ever since the device was first released. I'm fully familiar with the hardware layout and decoupling requirements, as suggested by Cirrus and several diyAudio members. In this context I would like to add that I find a lot of problems can be eliminated by feeding the VCC of the CS8420 through a ferrite bead. Cirrus don't stress the importance of this FB enough; it should always be fitted.
There were some early CS8420 silicon revisions (B and C) which had serious bugs - admitted by Cirrus FAEs to myself and colleagues - for which there were no workarounds. Silicon of Rev D (about 2000 vintage) is the first reasonable one. If you're using earlier ones, get rid of them.
I've generally found the 8420 seems to work more reliably in hardware mode than in software mode. In software mode they can be really, really EVIL, necessitating elaborate workarounds. One thing I would say here is that clearing the RUN bit before making configuration/clock/dataflow changes, and then setting it again after making the changes AND waiting for all signals to be stable, is imperative. Cirrus do not stress this enough.
I've also used the CS8427, which is a CS8420 with no SRC, and have experienced no problems with this chip in hardware or software mode. The CS8427 is made in a different foundry to the CS8420 and I suspect uses newer technology
DIYer's are more likely to use the CS8420 in a fixed configuration in hardware mode and should not find it too much of a Black Dog. But I still really wouldn't recommend anyone use the 8420 in software mode for new designs. Why punish yourself?
Regards
John Hope
Does CS8427 have problems like CS8420?
Hi everybody,
I have a Digital input board based on CS8420 and I experienced headaches similare to the ones that you all did.
Regard to this issue and because I don't use the SRC feature of CS8427, I'm going to replace this IC with CS8427.
I want to know if anyone has tried this IC? Is this IC more reliable than CS8420? Does it eliminate the problems and troubles that are with CS8420?
Regards,
M. Hafezi
Hi everybody,
I have a Digital input board based on CS8420 and I experienced headaches similare to the ones that you all did.
Regard to this issue and because I don't use the SRC feature of CS8427, I'm going to replace this IC with CS8427.
I want to know if anyone has tried this IC? Is this IC more reliable than CS8420? Does it eliminate the problems and troubles that are with CS8420?
Regards,
M. Hafezi
CS8427 vs CS8420
Hi
Assuming you definitely won't be needing a Sample Rate Converter, you could use the CS8427 instead of the CS8420. But beware: it's not quite a drop-in replacement.
In software control mode I think the codes that set up the device are not identical. If you're in software control mode you'd have to rewrite the s/w of your supervisory micro.
In hardware control mode, I can't recall if the pins that control the setup have the same functionality in both devices - check this out on the datasheets; if you're in hardware control mode you may have to hack pcb tracks and things.
Another pitfall is the PLL for the AES/SPDIF input. The 8420 and the 8427 are made with different fabrication processes and I'm pretty sure the PLL loop filter component values are different. Once again, check in the datasheet and in the myriad of errata and addendums and notes associated with the 8420; they seem to forever be changing the recommended values.
As to reliability, I haven't used the CS8427 as extensively as I've used the CS8420, but where I have used the '27 (software control mode, I2C interface), it's done exactly what it says on the tin and I've encountered no problems at all.
Cheers all
John
Hi
Assuming you definitely won't be needing a Sample Rate Converter, you could use the CS8427 instead of the CS8420. But beware: it's not quite a drop-in replacement.
In software control mode I think the codes that set up the device are not identical. If you're in software control mode you'd have to rewrite the s/w of your supervisory micro.
In hardware control mode, I can't recall if the pins that control the setup have the same functionality in both devices - check this out on the datasheets; if you're in hardware control mode you may have to hack pcb tracks and things.
Another pitfall is the PLL for the AES/SPDIF input. The 8420 and the 8427 are made with different fabrication processes and I'm pretty sure the PLL loop filter component values are different. Once again, check in the datasheet and in the myriad of errata and addendums and notes associated with the 8420; they seem to forever be changing the recommended values.
As to reliability, I haven't used the CS8427 as extensively as I've used the CS8420, but where I have used the '27 (software control mode, I2C interface), it's done exactly what it says on the tin and I've encountered no problems at all.
Cheers all
John
CS8420 hardware mode reset circuit
It has been suggested that I post this circuit which implements the hardware mode reset procedure described in the latest CS8420 datasheet.
Users of this circuit have reported that no further 8420 problems have been observed since fitting it. Any other flip flop can be used by configuring it for the proper type operation. The power comes from the same supply as the CS8420's.
http://cs.ubc.ca/~trifonov/rst.png
It has been suggested that I post this circuit which implements the hardware mode reset procedure described in the latest CS8420 datasheet.
Users of this circuit have reported that no further 8420 problems have been observed since fitting it. Any other flip flop can be used by configuring it for the proper type operation. The power comes from the same supply as the CS8420's.
http://cs.ubc.ca/~trifonov/rst.png
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.