There is no need to serialize or delay anything. The output from the PC software, be it Audacity, SOX, foobar, or any other source of sample data, is parallel. The input to the R2R array in the DAC is also parallel. The task of clocking sample data one sample at a time is easy; all you need is a sample clock. That's how it was done in the old days. Look at the PCM53, for example. The serial interface, common today, was adopted to reduce costs.
Unfortunately, DACs tend to be sensitive to amplitude noise and or timing noise (aka jitter). Perhaps more so for DSD than for PCM, but DSD has the advantage of avoiding element matching problems. IME its worth the effort to keep jitter low and use DSD.
A common fix for jitter is to reclock the I2S bus signals by some means. That generally involves at least a very short delay. However if FIFO is used the delay can be a second or longer. That said, I can see no reason why serializing should help. Usually SPDIF and or TOSLINK interfaces make jitter worse than is possible using well-designed USB interfaces. Unfortunately, not all USB interfaces are well designed. Also unfortunately, sometimes SPDIF jitter might help mask audibility of other problems, so it may be perceived as better in that case.
Last edited:
A CPLD in its simpler forms is no more than larger version of the 74 series logic used in said dac.
Complex Programmable Logic Device I think? With all switching being done on one wafer, are they prone to interference between the signal paths?
(hence discrete logic might sound better?)
Wondering exactly how you would get parallel data out of a PC?
I understand that the processor is working with parallel data, but I don't know how you'd access it. I don't know of any parallel interfaces you could add to a PC?
So I think saying this is easy is not realistic unless you know something I don't, which is entirely possible.
On the other subject, yes a CPLD is basically just a bunch of flip flips and gates in one big package. If the logic in the CPLD is at all complicated, it would take a large board full of discrete logic to replace it. Its someplace you don't want to go.
Discrete logic can easily spread switching noise to the whole board through ground and power lines (aka ground bounce).
How much switching is being done to output the sample stream on USB? How much switching is being done to convert the USB stream to S/PDIF? How much switching is being done to convert the S/PDIF stream to I2S? How much switching is being done to realign the I2S stream to interface with the R2R array? (The infamous I2S offset.) How much additional switching and extra bandwidth is needed to support the different interface protocols? All that switching is done at multiples of the sample rate and higher. What I am suggesting is a n-bit latch, clocked at the sample rate, where n is the width of the sample frame. To ease your troubled mind, the latch can be shielded and galvanically isolated.
The is of course exactly how it works. Jitter manifest itself as distorsion and perhaps noise. But no timing error as in the cymbal strike came a little late there.... no, by human, percivable timing error whatsoever. For sure.
//
It's very easy. Earlier generation PCs had unused, legacy parallel interfaces. Current generation PCs do not: But, inexpensive, PCI add-in PCBs can provide the missing interfaces. There are PCI prototype boards that provide the bus interface logic and lots of space to add your own specialized logic.
Last edited:
In asynchronous UAC the host-device (PC-to-USB board) interface can be 32-bit perfect so it does not matter how much switching is involved in that interface. Switching may become an issue downstream (I2S - glue logic - dac).
You do realize that legacy parallel interfaces and PCI add-in parallel interfaces are 16-bit. This dac is 24-bit.
You do realize that multiple 16-bit interfaces can be arranged to mimic the behavior of a wider interface.
Are you saying that with async UAC, all the clocks, latches, and logic necessary to transfer data between the PC and USB board and operate the USB 2.0 bus creates no switching noise?
I thought this forum was about DIY (Do It Yourself). Perhaps it should be renamed difmAudio (Do It For Me).
A standard ECP parallel port is only 8 bits wide. Once you start moving data in chunks all pretence to simplicity goes out of the window. Unless you plan to use PCI-X and that, of course, is really simple.