So you think a lot of people, including me (on my old notebook anyway), imagine audio glitches like VERY ANNOYING clicks or drop-outs with USB DACs?

That does not follow. I don't think anyone here doubts that audio drop outs can happen with buggy hardware. I've certainly seen data corruption from USB drivers for instance. Doesn't mean I think the MSC spec is broken.

Thats the problem with anecdotal reports about glitches. You don't know what caused it. Driver bug? Chipset errata? Problem with the USB spec? What conclusion can you safely draw when you don't know what happened?

What conclusion can you safely draw when you don't know what happened?

If a user that reported the problem reduces the DPC latency and the problems disappear then I draw the conclusion that most likely a too high DPC latency was the problem. Unfortunately, not all users can fix their hardware configuration / drivers so they end up returning the device and replacing it with an S/PDIF or Firewire or PCIe or async. USB interface which seem to make less problems. HDMI, as I said, I don't know.

On my old laptop, for example, disabling WLAN reduces the DPC latency considerably and gets rid of nasty spikes that caused drop-outs. Still not convinced?

I do have high DPC latencies sometimes in my laptop with Windows 7 and integrated realtek soundcard. And obviously, those spikes do cause clicks and glitches to the audio.

So talking about DPC latencies to say that USB audio fails is just attributing a problem A to an unrelated subject B.

In this regard, and if we consider "Laptop with windows Vista/7/8" a "player", then, ok, we can say that the player matters to get glitch-free bit-perfect digital audio playback. Otherwise, i'm with the usual thinking that digital is digital.

I do have high DPC latencies sometimes in my laptop with Windows 7 and integrated realtek soundcard. And obviously, those spikes do cause clicks and glitches to the audio.

So talking about DPC latencies to say that USB audio fails is just attributing a problem A to an unrelated subject B.

My laptop also has onboard sound and it works perfectly fine without glitches even though the DPC latencies go consistently crazy with WLAN enabled. It's just the USB audio devices (have not tried async ones) I've had problems with, but only with high latencies. This is in no way unrelated.

What's unrelated is saying the hardware is broken when it's clearly a software (driver) problem.

What conclusion can you safely draw when you don't know what happened?

If a user that reported the problem reduces the DPC latency and the problems disappear then I draw the conclusion that most likely a too high DPC latency was the problem. Unfortunately, not all users can fix their hardware configuration / drivers so they end up returning the device and replacing it with an S/PDIF or Firewire or PCIe or async. USB interface which seem to make less problems. HDMI, as I said, I don't know.

On my old laptop, for example, disabling WLAN reduces the DPC latency considerably and gets rid of nasty spikes that caused drop-outs. Still not convinced?

My old laptop and my new laptop run audio over USB just swell using a very basic interface - the Behringer UCA 202 with no parameter changes from defaults, and both or either WLAN or wired LAN active and in use.

There was a lot of discussion of asynch USB over at AVS a while back, and subtle SQ and jitter were the only issues raised. No advocate of Aysnch USB was able to proffer a DBT or any measurement that supported their claims. In short, each and every problem was perceived and subtle which is to say, probably imaginary. I'm not saying that Asynch can't be a problem solver, I'm saying that it is an effective solution that is in search of a real-world problem that is actually causing someone audible problems. OK, it finds a few such people. Next!

I think that we all know that measuring a problem or nailing it in a DBT are both slam dunks when the kind of problems you describe are active. Since this isn't happening, the basic problem must be pretty rare.

What I take away is that the problems you mention are rare, and when they arise they are due to pre-existing technical difficulties that are both far more global within the laptop, and/or also very much peculiar to the laptop sample where they are observed. Most people are interested in Asynch USB because they are led into it by people with commercial interests ar a desire to be opinion leaders, not because of any actual audible problems that they are experiencing. In many cases you can buy a whole new really pretty good laptop (or several!) for the price premium of the Asynch USB interface.

Also, it appears that adding Asynch mode to a USB audio interface may be just a matter of changing the firmware. It shouldn't be increasing the price of the equipment by 1,000% or 10,000% which it currently is doing.

The world is full of USB audio interfaces that served their owners very well without any asynch support at all. I can wait for it to become a standard feature, which might even take a few years.

My old laptop and my new laptop run audio over USB just swell using a very basic interface - the Behringer UCA 202 with no parameter changes from defaults, and both or either WLAN or wired LAN active and in use.

I think that we all know that measuring a problem or nailing it in a DBT are both slam dunks when the kind of problems you describe are active. Since this isn't happening, the basic problem must be pretty rare.

What I take away is that the problems you mention are rare, and when they arise they are due to pre-existing technical difficulties that are both far more global within the laptop, and/or also very much peculiar to the laptop sample where they are observed.

These problems are not limited to laptops. In fact, for example, certain nvidia driver versions had horrible latency problems. So do/did other devices' drivers.

QUOTE

Most people are interested in Asynch USB because they are led into it by people with commercial interests ar a desire to be opinion leaders, not because of any actual audible problems that they are experiencing. In many cases you can buy a whole new really pretty good laptop (or several!) for the price premium of the Asynch USB interface.

Also, it appears that adding Asynch mode to a USB audio interface may be just a matter of changing the firmware. It shouldn't be increasing the price of the equipment by 1,000% or 10,000% which it currently is doing.

I don't know about the firmware but I agree with the other points you make. I'm not advocating to buy an async interface either. As you've said it's probably cheaper to get a better laptop or PC that will run flawlessly with the interface.

All I'm saying is that even if the output is digital the player (a computer in this case) can make a difference under certain circumstances. These circumstances are certainly not the rule but those problems do exist and I wouldn't say they are pretty rare.

My old laptop and my new laptop run audio over USB just swell using a very basic interface - the Behringer UCA 202 with no parameter changes from defaults, and both or either WLAN or wired LAN active and in use.

I think that we all know that measuring a problem or nailing it in a DBT are both slam dunks when the kind of problems you describe are active. Since this isn't happening, the basic problem must be pretty rare.

Right, it's so rare that pro audio manufacturers have articles on this problem.For example: avid/m-audio kb

Mentions tics and pops which asynch I/O being not a perfect panacea, may not address. Does not recommend or even mention Asynch USB.

Mentions tics and pops which asynch I/O being not a perfect panacea, may not address.

How do you know that?

QUOTE

Does not recommend or even mention Asynch USB.

Right, any manufacturer should recommend that if their users have problems with their own hardware to buy a new interface with async. I/O. Preferably from a different manufacturer. Makes sense.

later you even posted:

QUOTE (Arnold B. Krueger @ Aug 3 2012, 17:59)

I agree because I know of no traditional pro vendor audio interface who is active with asynch USB interfaces. By active I mean formally announced or delivered products.

Those articles mention DPC latency as being one source of the problem. You said those problems must be pretty rare. I disagreed and posted those links. That's all there is to it.

QUOTE

What is the relevant "it".

I was talking about DPC latency problems, which should be blatantly clear by now.

QUOTE

My comments about rare were in the context of a discussion of asynch USB.

What? So what rare problems in the context of async USB are you talking about then?To me it seems you're trying to avoid the DPC latency issue now after you've seen that even manufacturers acknowledge it's a problem.

QUOTE

If it was really common people would be lining up to buy and no market stimulation would be required.

Mentions tics and pops which asynch I/O being not a perfect panacea, may not address.

How do you know that?

Simple. The tics and pops come from data that is lost inside the PC. We've had these as long as we have had computer interfaces that were entirely internal to the PC, and long before USB or even SPDIF.

It is very simple.USB Audio is a isochronous stream, the track is decoded and stored in a buffer in memory. It is spooled from memory to the internal USB hub and then from the hub to the USB DAC. The internal hub reserves sufficient bandwidth for the audio stream.

There are 2 type of errors possible.DPC latency problems simply means the PC is too late in feeding the internal USB hub so it can’t maintain the needed quasi real time stream.Obvious DPC is a upstream problem (before the internal hub) and therefore the method used to sync the audio device has no relevance.No USB (audio) device is able to control what is happening upstream.

Sometimes there are CRC errors. Here the bits got mangled between the hub and the audio device. Compared with DPC they are a bit rare but they can happen. As the UAC1/2 protocol doesn’t have a retry like all bulk mode device, this might yield clicks, pops, etc as well.

You won’t find many pro audio interfaces using USB audio (UAC)The reason is probably that up to 2009 there was only UAC1 and this standard is limited to 2* 24/96.If you want to do a multi channel recording with low latency, this won’t do.Most pro USB interfaces (e.g. RME) use bulk mode. As a consequence they do have to write their own device drivers at the PC side.By design bulk mode is async.

There are a couple of exiting developments going on in the Android worldOne is the implementation of UAC2 (USB Audio Class 2)However this is the straight “old” Linux stuff.There are a couple of new developments going on and I must admit I’m totally at loss where it is about technically and sound quality wisehttp://thewelltemperedcomputer.com/SW/Andr...Android_USB.htm

There's a lot more places to lose data in a computer than just a USB link. On paper, many look like they should be abundantly fast and never lose a sample. But in the real world, stuff breaks and other tasks interfere. Data gets lost and you have a click or a pop. I'm not going to teach a computer architecture class, but there's where the answers lie.

I'm absolutely convinced that you have broken hardware. Beyond that, what else am I supposed to take away from the anecdote?

Well that's just (being) stupid but I'm okay with that.

What a tactful way to avoid answering the question.

QUOTE (xnor @ Aug 2 2012, 16:57)

I don't know about the firmware but I agree with the other points you make. I'm not advocating to buy an async interface either. As you've said it's probably cheaper to get a better laptop or PC that will run flawlessly with the interface.

No, its cheaper just figure out what broken device you have that is blocking inside an ISR (!!!) and throw it out a window.

@roseval So am I right in thinking this would be implemented through software on new android devices rather than hardware (the USB port is already there right...) so would older models be able to use it?

The USB DACs being UAC1 or UAC2 compliant (use the native mode drivers as supplied by the OS for USB Audio) will work when UAC1/2 is implemented in Android.Android is based on Linux and ALSA does have the drivers.Obvious this is a matter of software.A couple of mobiles already do: http://www.audiocircle.com/index.php?topic=103447.0

The architecture as proposed by Google (the device, in this case the DAC) provides the power, not the host (e.g. a mobile running Andoid) needs different hardware.