Thanks Jerry,
I don't suppose all this is documented somewhere? Most of the
documentation I've read so far is worded to the effect of "Microsoft
strongly suggests not writing your own driver and using usbaudio
instead".
Keeping a major detail like latency and synchronization problems
"hidden" could be very dangerous to vendors who are led to believe
that making their device UAA / WHQL compliant is a viable solution on
Windows. It may be viable for OS X, but on Windows, especially where
kernel mode development is involved, there's a huge difference in time
and resources needed between simply making the device compliant, and
"rolling" your own driver.
I don't mean to be rude, but frankly, I don't know why there is even a
question of "Why would you want USB Audio 2.0 in Windows?". The
question should be "Why wouldn't you?".
------------------------------------------------------------------------
*From:* Jerry Evans <jerry@xxxxxxxxxxx>
*To:* wdmaudiodev@xxxxxxxxxxxxx
*Sent:* Fri, October 23, 2009 3:03:55 PM
*Subject:* [wdmaudiodev] Re: usbaudio 4ms in Vista / Win7 myth?
FL:
Your observations and inferences are pretty much spot on. The XP stack
as an inbuilt 10ms long buffer (at 44K1). This accords with the
default buffering used (AFAICR) in PCI audio driver samples. Why? Who
knows. I asked out the same thing years ago in this NG and ended up
assuming it was 'about right' for the processors of the period.
The only way to get less buffering is to roll your own USB driver. On
7 it might be possible that WASAPI exclusive mode means reduced
latency. That is the theory for PCI devices but I have not tested this
proposition. Exclusive mode is still, AFAIK, broken for Vista.
I do hope those nice people in the driver division take account of
latency in any forthcoming USB 2 class driver ..
Jerry.
First Last wrote:
Hi,
I have an USB Audio Class device, which I've been using on XP x64
with usbaudio.sys and the asio4all driver. I've been using usbtrace
to look at the actual packets to try and determine the actual latencies.
It seems usbaudio.sys always asks for 10 packets at a time (i.e 10ms
of data) from the IN endpoint, however, when using the asio4all
driver I see that usbaudio can send as little as 1ms at a time, which
is great. I understand that usbaudio is still usb 1.0, so anything
less than 1ms is not possible given that it cannot support any
interval other than 1 (meaning only frames, no microframes for packets).
So I have a couple questions regarding this...
1) Why 10ms only for the input stream? If you take into
consideration the round trip latency 10ms input + ~2ms audio
processing + 1ms output + (whatever time it actually takes to go up
and down the stack), that's like at least 15ms in a best case
scenario with usbaudio, no? more? Anyone who plays an instrument,
even someone who doesn't know how long 15ms is or how many feet from
the speakers that equates to will tell you "that doesn't feel
right". Why so much latency on the input stream?
2) I've heard rumors that in Vista / Win7, that it uses packets in
groups of 4 instead of 10, or 4ms at a time. How do you get this
elusive number? I have a Win7 test machine here, and darned if it
doesn't still ask for 10 packets / ms at a time. Is 4ms a myth? How
is the NumberOfPackets determined? Is it determined at the kernel
level? in usbaudio? or perhaps even in the descriptors of the
device? Or is it enforced by DirectSound, or I suppose DirectKS or
WaveRT when using ASIO? How do I get that magic number?
Any suggestions welcome, thanks.
