|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
131.107.71.94
In Reply to: Re: How do these modded USB Dacs really work? posted by audioengr on October 27, 2004 at 16:27:03:
Thanks for the explanation.You are basically replacing a synchronous transport (S/PDIF) with an isochronous (USB) that sits over an asynchronous token bus with retransmission and recovery. You rely on the USB chip and its buffer to hide those details from you and give you a constant rate stream.
However you are still need to reconstruct the clock from the incoming signal and use a PLL to adjust your local clock speed to match the incoming rate.
Does that sound halfway right?
Why would you not want to use the asynchronous USB audio mode and get rid of the PLL and just let the local clock be in control?
Cheers
Thomas
Follow Ups:
Does that sound halfway right?Sounds right to me.
Why would you not want to use the asynchronous USB audio mode and get rid of the PLL and just let the local clock be in control?
The chips that are available use a PLL or DLL of sorts to resolve the difference between the incoming data rate and the locally generated S/PDIF clock according to the data sheets. I believe if the local clock was in control, that the push model might fall apart when you have an underrun. You can read the spec sheets on the TI tas1020a or the TI PCM2707
I understand that but why would you want to use a push model to begin with.All the translations USB -> S/PDIF - S/PDIF - I2S - DAC would not really matter if the only clock that matters is the one that drives the DAC. Fundamentally the clock of the dac would determine the (presumably very stable) rate at which the audio data is converted. The clock of the I2S and S/PDIF links would be directly derived from this master and run completely synchronously.
The USB / S/PDIF chip would simply use flow control back to the PC to always have enough data in the buffer to maintain an uninterupted flow.
This setup could achieve the highest possible conversion quality at very low cost.
The USB solution outlined in the earlier post is a way to connect a DAC directly to a USB port but as far as I understand has no great benefit to the jitter problem.
Cheers
Thomas,From what I have read AUDIOENGR uses the TI PCM2707, this is a DAC with SPDIF output. He probably made up a small board with this on it and the supporting circuitry and links the TTL level SPDIF signal directly into the SPDIF reciever at the same level.
The clock into the PCM2707 is not as critical because it is going into a quality clock generator for all the internal stuff (sigma-delta output filters, SPDIF clocking, internal USB, etc). Therefore there is no need to have a secondary PLL for this. The SPDIF is already to go out of the PCM2707.
My dac does use the ASYNC mode and I2S out to the dac is rock on and some of the best sqaure wave preformance I have seen from a digital receiver.
I though audioengr typically modded M-Audio Transits which support 24/96 which (unless I'm misreading the data sheet or M-Audio is fibbing) the 2707 doesn't support. Does something like the transit use a custom/discrete approach?
The Transit uses a TI tas1020a and a CODEC. And yes, I use the Transit board to mod because it passes 24/96.
Thanks GordonNow we are getting closer to what I was hoping for. So in your case you do actually only use the local clock to drive the flow of data from the PC? Do you use the standard system supplied USB audio driver or do you ship with your own?
After quickly scanning the PCM2707 manual it looks like this solution is using isochronous mode and extracts the clock from this signal with the changes moderated by an analog PLL. Then it outputs a synchronous S/PDIF signal which then will have to be extracted and reclocked again before handed to the actual DAC chip. What exactly is the purpose of this approach? This is not liekly to reduce jitter, is it?
Cheers
Thomas
Thomas,You can use the PCM in several ways though kinda of hidden in the data sheet. It can be used ASYNC as well as isosynchronous.
In ISO mode the clock is pretty stable as the USB controllers on the computer side have a large enough buffer as to not conflict with the speed. Therefore the SPDIF could go directly to a SPDIF receiver and out in the format needed for the particular dac chip required. No other clock needs to be applied.
Jitter in this regard is reduced because there is no relationship to the dive mechanism and position of the head which is more of an issue with jitter that I have tested. This is what led me to do a USB dac. When I was working on a secondary PLL for a crystal receiver I was shocked at how much the clock changed in relationship to the position of the head. So too the amount of jitter. That and crappy MCLK's in even expensive transports.
Therefore USB to SPDIF will result in lower Jitter than say transport to DAC directly.
This is also true (at least with iTunes) that when a CD is played it is buffered to the tune of a few buffer lengths of the USB buffer required by the controller.
This post is made possible by the generous support of people like you and our sponsors: