|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
66.42.245.53
In Reply to: Re: USB output question posted by drminky on October 27, 2004 at 04:29:08:
DrMinky,The airport express actually uses a USB -> SPDIF convertor inside here is how it works....
802.11 <=> Processsor <=> USB Controller port a -> Printer
|-port b ->USB DAC w/SPDIF-> Analog & ToslinkSo in a sense you do get the lower jitter, still there is the problem of being SPDIF and more so that it is Toslink.
My Airport express is chopped and outputs USB audio right now cool...
Follow Ups:
Gordon, Could you please provide more information how to mod Express to get the USB signal out?BTW what chip are they using to convert USB to SPDIF?
Rafal,I did not take notes but this is basically what I did. There is an audio board, which I removed. Before I did I use a voltmeter to determine which pins on the header where D+, D-, 5+ and GND.
The DAC is the TI PCM2707 which is the same one the AUDIOENGR uses in his modification of DAC's from what I have read.
Then I just lopped off a USB cable, omhed out the pins and soldered them to the header.
Bugger is a bit diffacult to open. Maybe you may want to find one of those iPod splitters before you try.
Could someone shed some light into what the actual benefit of these USB modded DACs is. I have been reading about it but I am puzzled as to what they really do.USB is a token based bus with CRC based packet integrity and retransmits on corrupted packets. The USB audio profile allows for isochronous or asynchronous tranfer with flow control.
In both cases the audio needs to get buffered at the receiver. In isochronous mode the source of the data controls the rate at which the data is sent out while in the asynchronous mode the sink is in control and can completely decouple itself from the incoming data rate.
By adding a USB port to a DAC which of the above options do I get? Do I need to install a special driver on Windows to make this work?
Cheers
the benefit is that they eliminate or minimize the effects of the S/PDIF interface. Usually, there is a USB interface chip that does some small buffering, but the USB data rate is much higher than the native data rate, so that when the data gets reclocked and sent out of the chip in the native data rate, the jitter is very low. Mostly a function of the crystal oscillator and PLL in the chip. This oscillator can be a Superclock2 for instance, making it very low jitter indeed. I believe it is usually a "push" model with flow control.
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
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: