[thomaspf]

For some years now we have been discussing the merits of connecting a DAC to a computer via USB. The original USB Audio 1.0 spec was issued almost 10 years ago and it defined 3 different connection models.

The key difference for these connection models is the location of the master clock. Almost all available USB audio devices treat the USB connection very similar to a one directional S/PDIF connection. The master clock for the playback chain is located in the PC and a USB connected DAC needs to estimate the clock from the data stream send to it from the PC.

A lot of engineering IQ has been dedicated to reduce the jitter inherent in such a solution but now you can get a DAC that implements asynchronous USB audio mode.

Wavelength Audio has a new version of their Crimson DACs that operates in async USB audio mode. In this mode the master clock is local to the DAC and a backchannel on the same USB cable is used to slave the data stream from the PC to that clock. Only this connection mode allows you to use a highly stable clock in the DAC to drive the converter directly. As another benefit this works without requiring any additional drivers in Windows or MacOS.


I have no association with Wavelength other than having argued for a long time on this forum and in private that Async mode is the right way to go for high end DACs.

My congratulations for finally making it happen!

Cheers

Thomas

 

[infinitesymphony]

Sounds very interesting... I'm eager to see how this pans out, and if it trickles down to regular USB audio interfaces.

 

[thomaspf]

The key breakthrough is the programming of the TAS1020 chip to support async mode. This chip is used in quite a few mainstream USB DACs.

Then you need to think about how you built a stable local clock that drives the converter directly and the clock input of the TAS1020 in a synchronous way.

I am not sure whether Wavelength is planning to license the code to interested parties but the fact that it got done probably inspires others.

For me it is just a happy day to see this finally come through.

Cheers

Thomas

 

[infinitesymphony]

So, since this is partly a software solution, do you think that we might start seeing manufacturers issuing firmware updates, or is the custom clocking mechanism also essential to the improvement?

 

[Jon L]

This is indeed good news, but I doubt Gordon would feel like licensing it out to basically his competitors after putting in the grunt work for rewriting the TI code.

However, from the way it works, it seems like the code can be written by others as well.

Computer Audio Asylum - RE: Asynchronous USB for Wavelength Crimson - Gordon Rankin - November 30, 2007 at 07:09:08

 

[thomaspf]

Well, TI did not really think it could be done and the spec is not exactly crystal either. Then there are a few details in how the Windows driver works so even this proof of existence might not lead to an avalanche of async mode implementations.

I might speculate, however, that licensing this intellectual property for a decent price might turn out to be an interesting business on it's own. Centrance licensed their TAS1020 firmware to Benchmark for the DAC1 and that is just doing slightly better buffering and registers as only supporting 24 bit streams.

Cheers

Thomas

 

[Scrith]

Sounds like an interesting technical milestone has been reached.

Now for the part that actually matters: can anyone hear any difference in a blind test?

 

[Wavelength]

Thomas, others;

Thanks for the nice comments. It took over 900 hours of work to get this going.

The problem with the TAS1020 is that it does not support ISO mode, except when connected to a dac or adc (via DMA). This caused a problem because in ASYNC mode you actually send what is called a feedback ISO pipe of 3 bytes of data. This basically tells the computer to speed up, slow down or continue sending the data at the same speed.

I basically sat in front of the emulator and compiler for 3 weeks trying to get this to work.

Yes this is software but it is specifically written for the TAS1020 USB Audio controller.

Since CES is only a few weeks off AHHHHHHHHHHHHHH we will see what if any licensing comes out of the show.

A funny thing happened in BETA1 of this code. In some OS's it would click every ounce and a while. I started looking at buffering and stuff and totally changed how it worked after I studied the way XP, Vista, OSX10.4 and 10.5 work. Too my surprise each one worked differently in ASYNC mode. I totally rewrote my flow control after looking at these. It now works much better than before.

Thanks again,
Gordon

 

[Crowbar]

Quote:

Originally Posted by Jon L /img/forum/go_quote.gif This is indeed good news, but I doubt Gordon would feel like licensing it out to basically his competitors after putting in the grunt work for rewriting the TI code.

That assumes one insists on using the TI chip.
My partner wrote the async code in C and it's running on a Cypress chip--and probably saved us a lot of headaches. From what I remember Gordon used assembly... Mr Rankin you're a masochist, 900 hours >.<
I remember there was a company that wrote the USB firmware for Benchmark, and when I asked them they said they did have async support, however their licensing fees were too much.

 

[DefectiveAudioComponent]

Doesn't the 0404 has it own clock as well, for instance? It looks like that in the manual. What's the difference... is it possible to explain?

 

[Crowbar]

There are probably two clock domains--the 0404's own, and the PC one, and an ASRC converting from one to the other. Indeed, this is what Benchmark does as well.

The problems of ASRC are discussed on Bruno Putzeys section in the prosoundweb forums (he used to be chief engineer at Philips Digital Systems Labs for class D audio so he knows his digital).

The alternatives to ASRC are:

- deriving the clock from the incoming stream with a PLL and filtering the jitter down, which is what most regular DACs do, and is the worst solution with the exception of a few DACs I've read about that used fancy dual PLLs to get very good cleanup of jitter in the audio band

- as above, but using a high quality digital PLL that can completely filter out jitter in the audio band; this is what the brand new ESS Sabre DAC chip does

- send the DAC clock back to the source over another cable, or scrap S/PDIF and use a custom interface that accomplishes the same, and so then the incoming stream only needs to be reclocked and maybe slightly buffered; this is what a few high end DAC/transport pairs do, and a number of DIY designs

- use a VCXO (adjustable clock) and a buffer and slowly (at rate below audio frequency) speed up or slow down the clock to keep the buffer from under- or over-flowing; this is what some Lavry DACs do (and others don't even though they were supposed to

)

- a variation of the above with a fixed DAC clock hopefully close enough to the jittery source clock and a very deep buffer that is emptied or refilled depending on whether it's close to under- or over-flow during moments of silence in the music (such as between tracks); I have only seen one design (a DIY one) that implements this, and maybe some MSB DACs do but I can't remember and I'm too lazy to look it up, and this option suffers from latency and is unusable in cases where you need to have audio synchronized with say video, as the timing could become as much as seconds off

- use an asynchronous interface, which is what these new Wavelength DACs do (and I as well, though the rest of my DAC isn't ready yet)--this is purely a digital interface with no analog timing data transmitted, and is the proper solution that should have been standardized from the beginning, instead of the misery of S/PDIF necessitating various complex and non-standard workarounds

 

[sejarzo]

Don't think that the 0404 USB uses ASRC.....

Gordon, correct me if I am wrong, but you were the one who rooted out the way that E-MU wrote their drivers, correct? I can't recall if you posted that here or on Audio Asylum, but it seems that you mentioned this in a thread that also involved Steve Nugent, perhaps?

This is my understanding:

The 0404 USB driver uses "bulk mode" to transfer the audio data stream without a clock to a buffer in the external box, from which it's reclocked internally to the DAC section.

Is that, in a nutshell, the best way to explain it?

I have noted some different behavior between my desktop and notebook....in Foobar 0.8.3 and either of the resampler plug-ins that are installed, I can switch sample rates "on the fly" in the middle of a cut with the notebook, and the 0404 USB resyncs with nothing more than a tiny audible click...the tempo and pitch don't change. Made it easy to A/B the effect of resampling, eh????

However, on my desktop, if I do that same thing....start playback with no resampling, then switch from 44.1k to 96k in the resampler plug-in, the tempo and pitch drop.....and vice versa, if I start playback at a higher rate and drop back to 44.1, the tempo and pitch go up.

All I can deduce from that is for some reason, with my notebook the driver is able successfully "tell the box" that the data it's being sent should be reclocked to the DAC at a different rate......but something on my desktop prevents that, and the "box" still "thinks" it should continue clock incoming data at the rate valid when playback of that cut was started. If I stop and restart playback, it always seems to sync up correctly.

Seems to me that's evidence that the 0404 USB isn't impacted at all by any clock on the PC side.

 

[thomaspf]

I have not looked into what EMU is doing but if you write your own audio driver for Windows you can basically use USB in whatever mode you want.

In order to play music out of that DAC you have to install the matching EMU driver. Driver issues turn out to be the biggest root cause of problems with your PC.

The interesting thing about Gordon's and it seems Crowbar's async USB device is that their implementation does not require any additional drivers. You simply plug these devices into a USB port on any PC running Windows I assume Linux as well and with a single cable you will get a playback chain with the master clock located in the DAC. The USBaudio.sys driver on Windows has been pretty stable for many years now.

Cheers

Thomas

 

[gsawdy]

I don't want to hijack this very interesting discussion as it has already clarified a number of comments pro and con re USB sources--Thank you all.

I'm trying to design a multi room system for my house so I'm looking at some sort of external sound card that has a minimum of 10 analogue outs. Something like either the Edirol UA 101 or the FA 101. What I'm trying to get my head around is the relative advantages/disadvantages of Firewire vs USB2. I know firewire had a head start in that USB1 was MUCH slower. But USB2 on paper seems to have caught up speedwise although firewire has moved on to 800 for the best pro systems. Whatever system was employed for the sound card, the other would be used for hard drives and backup.

There seems to be considerable wisdom collected on this thread and I would appreciate if anyone can offer any informed reasons why one or the other is preferable. What do I look for to see if the pro USB systems have dealt with the jitter issue? Is firewire inherently more immune from jitter issues? Any links would be appreciated. BTW here is an interesting link documenting the jitter reduction abilities of RME's SteadyClock: RME: Support TechInfo

Thanks to all
George

 

[thomaspf]

From the limited sampling of USB audio adapters that I have seen the pro models do not rely on isochronous USB streams for transporting the audio to the device.

The custom drivers use reliable streams with retransmission etc. What this means is that similar to async USB the clock resides in the device and the PC is simply as data source slaved to that clock. No worries about jitter. Some of these pro audio devices even have an external word clock input so you can synchronize them to a house clock but for your playback only scenario that is likely not necessary.

Which application are you planning to use drive the multi-room setup?

Cheers

Thomas