Re: USB output question - ThomasPf 13:12:08 10/27/04 (0)
 Re: USB output question - audioengr 10:41:05 10/27/04 (0)
 Re: USB output question - drminky 04:29:08 10/27/04 (13)

...

Show full thread outline!

 Re: USB output question - ThomasPf 13:12:08 10/27/04 (0)
 Re: USB output question - audioengr 10:41:05 10/27/04 (0)
 Re: USB output question - drminky 04:29:08 10/27/04 (13)
 Your wrong about the Express - Gordon Rankin 08:02:44 10/27/04 (12)
 Re: Your wrong about the Express - rafalc 08:37:45 10/27/04 (11)
 Re: Your wrong about the Express - Gordon Rankin 09:19:57 10/28/04 (0)
 How do these modded USB Dacs really work? - ThomasPf 13:20:49 10/27/04 (9)
 Re: How do these modded USB Dacs really work? - audioengr 16:27:03 10/27/04 (8)
 Re: How do these modded USB Dacs really work? - ThomasPf 17:45:27 10/27/04 (7)
 Re: How do these modded USB Dacs really work? - audioengr 16:47:07 10/28/04 (1)
 Re: How do these modded USB Dacs really work? - ThomasPf 20:16:57 10/28/04 (0)
 Thomas some answers - Gordon Rankin 09:29:01 10/28/04 (4)
 2707 vs others? - dwk 15:10:56 10/28/04 (1)
 Re: 2707 vs others? - audioengr 16:50:51 10/28/04 (0)
 Re: Thomas some answers - ThomasPf 09:53:05 10/28/04 (1)
 Re: Thomas some answers - Gordon Rankin 12:06:06 10/28/04 (0)

However, AFAIK, you will lose any usb-audio advantage in the conversion. It will be just like any other toslink or spdif transport (perhaps a bit less jitter coming from a hard disk). The get the full benefit from usb audio, the only option I know of is to get your dac modded to put a usb2 (preferably) interface directly into the dac itself, so no conversion takes place (or get another dac, such as a twindac).

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 & Toslink

So 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...

Thanks
Gordon
J. Gordon Rankin

BTW what chip are they using to convert USB to SPDIF?

Thanks
Rafal

The Transit works superbly with a PC, but I have heard some anecdotal evidence that with Apple gear, the Edirol is better. Probably S/W drivers etc..

Cheers

Thomas

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

Thomas

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

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.

Thanks
Gordon
J. Gordon Rankin

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.

Thanks
Gordon
J. Gordon Rankin

Now 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

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.

Have fun,
Gordon
J. Gordon Rankin

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

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