On Dec 21, 2005, at 10:46 PM, Torrey Holbrook Walker wrote:
Hi Philippe,
In the USB 1.1 audio class specification, there doesn't appear to
be a way to have input and output locked to the same sample rate.
The USB 2.0 audio specification does have a very clear definition
of clock domains and new descriptors to address issues like this,
Just to avoid a confusion. I've read in some postings that a 2.0
version of the Audio class specifications is being finalized. To my
knowledge, the current released version of the Audio class
specifications is 1.0. To my understanding, USB 1.1 is the last
released version for the full speed bus (the whole bus specs), and
USB 2.0 the last released version of the high-speed bus (the whole
bus specs, including full and low speed features). So, when you
mention the "USB 2.0 audio specification" do you refer to the "high-
speed bus" specification or to the yet-to-come 2.0 audio class spec?
but if you want to implement something like this in a class-
compliant manner, the best advice I can give is to provide a
hardware sample rate switch/knob. The expected behavior is that
when the switch is moved from, say, 44.1 kHz to 48 kHz, the device
will drop off the bus and re-enumerate with a new descriptor
specifying 48 kHz as the only valid sample rate for input and output.
That's a good idea. I'll try it. The point is then how will behave an
audio app if the device disconnects and reconnects while it may be in
use?
My second concern is what processing do I need to apply to the OUT
stream (ie the input stream from the device point of view) to get it
in synch with my local oscillators (the device audio clock).
The way AppleUSBAudio handles the input stream (to OUT endpoint
type 0x101) is to always request the maximum number of bytes that
can be received for every USB frame. In most cases, AUA expects the
actual number of bytes to be less than the maximum it can receive
at any given time, and it copies over however many bytes were
transmitted before converting them for CoreAudio. In this way, the
device is totally in control of the input sample rate.
AppleUSBAudio takes the device's word on the nominal sample rate,
and the rate at which bytes are copied into the ring buffer
determines the actual sample rate that CoreAudio calculates for
input. If the time stamps that are taken when the driver wraps
around the ring buffer are correct, CoreAudio should have a good
idea of the sample rate on the device.
For output, however, you will notice that AUA uses a very
mechanical method to decide how many bytes are written on each USB
frame. The only way this changes is if a feedback endpoint is
available to more closely regulate the sample rate. If the input
and output stream need to be synchronized, a feedback endpoint
provides a good way to make these small adjustments to keep input
and output in sync.
I had a look to the chapter 5 (section 5.12) of the USB 2.0 spec.
There's a long development about synchronization method for
isochronous devices. These methods are well summarized in the
informative posting from Markus Medau (same thread).
It seems that the Apple driver implements the "explicit" feedback
endpoint synchronization method. I suppose that some buffering is
needed at device level. Any idea of the amount of buffering (it has
an impact on the latency of the system and it's an important point
for us)?
Beside the use of a "feedback endpoint", the standard points on the
possibility to use "implicit feedback" provided that the device
complies to some "constraints" on its endpoints (satisfied by my
device). If I have correctly understood, the principle is to deduce
the data rate to use on the OUT stream from the data rate measured on
the IN stream. Hence my question: does the AppleUSBAudio driver
implements this "implicit feedback" algorithm?
If yes, would it work also with "old" Apple computers which are
"only" 1.1 USB host (e.g. G4 MDD)?
Philippe
------------------------------
_______________________________________________
Coreaudio-api mailing list
email@hidden
http://lists.apple.com/mailman/listinfo/coreaudio-api
End of Coreaudio-api Digest, Vol 2, Issue 399
*********************************************