Home
AudioAsylum Trader
Computer Audio Asylum

Music servers and other computer based digital audio technologies.

For Sale Ads

FAQ / News / Events

 

Use this form to submit comments directly to the Asylum moderators for this forum. We're particularly interested in truly outstanding posts that might be added to our FAQs.

You may also use this form to provide feedback or to call attention to messages that may be in violation of our content rules.

You must login to use this feature.

Inmate Login


Login to access features only available to registered Asylum Inmates.
    By default, logging in will set a session cookie that disappears when you close your browser. Clicking on the 'Remember my Moniker & Password' below will cause a permanent 'Login Cookie' to be set.

Moniker/Username:

The Name that you picked or by default, your email.
Forgot Moniker?

 
 

Examples "Rapper", "Bob W", "joe@aol.com".

Password:    

Forgot Password?

 Remember my Moniker & Password ( What's this?)

If you don't have an Asylum Account, you can create one by clicking Here.

Our privacy policy can be reviewed by clicking Here.

Inmate Comments

From:  
Your Email:  
Subject:  

Message Comments

   

Original Message

RE: How can USB performance impact audio quality?

Posted by John Swenson on June 12, 2011 at 20:02:54:

This has also bothered me for some time, especially when you have an asynchronous interface which is supposed to prevent such things from happening.

After a LOT of investigation and experimentation I now think I have a somewhat decent handle on it, as Tony mentioned it all comes down to good old fashioned analog noise and in particular the spectrum of said noise and how this changes with whats going on in the computer etc.

I and others have built DACs with exquisite high quality power supplies etc which is supposed to prevent any coupling through the PS. BUT this ignores the ground plane. After you get everything else cleaned up you have to deal with ground noise, and this is particularly difficult to deal with.

As to how this is important I'll cover a scenario with USB, I'm assuming this is already an extremely well done async interface.

A packet comes in over the cable and goes in the receiver chip. This chip does a lot of stuff with this packet and eventually puts some bits in a buffer that down stream circuits extract using its super stable ultra low jitter clock. But what does all that processing in the receiver do? It generates noise on both the positive supply rail AND the ground plane. Any good design is going to have separate voltage regulators that prevent the noise on the positive supply rail from reaching any other circuits (such as the ultra low jitter clock, DAC chip, analog stage etc). BUT those don't work for the ground. If you are not EXTREMELY careful, some of that ground noise from the receiver is going to be on the ground pins of the other parts. If you just use a common ground plane you are almost guaranteed to have this. No its not huge, but its still there.

The interesting aspect of this noise is that if you look at the spectrum of it you see a strong 1KHz component, which is the packet rate on the USB bus. This falls right smack dab in the middle of the audio range. It gets even worse. In most circumstances the exact time at which packets are sent is controlled by software, NOT a low jitter hardware clock. This means that things like kernel scheduling policies, interrupt latencies etc have a HUGE impact on the exact timing of those packets. It comes out to close to 1KHz all the time, but there is significant variations on the exact time between packets. This causes that 1KHz component of the ground spectrum to spread out, it has "skirts". This "modulation" is in the low end of the audio range. There is a fair amount of evidence that this type of low frequency jitter can make subtle changes in the listening experience even when it is fairly low level.

Unfortunately this can make USB DACs quite susceptible to all kinds of things that happen on computers. The player software used, what audio stack is used, kernel parameters, timing on memory chips, all kinds of things can cause subtle changes in the packet timing on the bus.

There IS a way to cut down on this, use separate ground planes so noise on the receiver does not get into the sensitive area. This is a lot easier said than done. One way is to completely isolate things, but then you need something like an optoisolator or transformer for the data. None of this is easy and usually adds significant amounts of jitter.

The other way is to make sure there is one and only one connection between ground planes (which is right underneath the data lines). This actually does work and does not require isolating the data, but it DOES require one and only one ground connection. This means it takes separate power supplies.

To REALLY do it right requires multiple domains each with its own separate power supply and very careful ground plane management. Unfortunately this is neither easy or cheap. It takes a lot of work to design this and it takes a lot of money. But when done right the results are spectacular. But it means that any DAC done this way is going to cost a lot of money, there is just no way around that. And that's not even using boutique components.

The fun part is to try and come up with a design that tries to do the above but doesn't actually fully implement it. There are a LOT of different compromises that can be done for various different price points. This is where I think the biggest challenge is going to be, how to do it well (not perfect) without costing a fortune.

So the state of affairs right now is you can spend a lot of money and get something that is fairly immune to whats going on in the computer (not completely, there are some third order affects that are REALLY tough to get rid of), or pay a small amount of money and really have to tweak the computer to get really good sound. Unfortunately there is no cheap and always sounds great, it doesn't exist.

There is a lot more to say about this subject, but this is already way too long so I'll stop now.

John S.