Re: Synchronizing with the actual USB device audio clock
Re: Synchronizing with the actual USB device audio clock
- Subject: Re: Synchronizing with the actual USB device audio clock
- From: Jeff Moore <email@hidden>
- Date: Tue, 20 Dec 2005 17:04:54 -0800
On Dec 20, 2005, at 4:06 PM, philippe wicker wrote:
Let's focus for the moment on the USB OUT stream (the input stream
to the synth). This audio finds its way to the DACs which are
clocked by a local crystal oscillator at - say - 44.1 KHz. My
question was: how the USB host knows of the actual device clock.
What I understand from your answer is that the USB controller knows
nothing of the device clock. It has been told that the sample rate
is 44.1 KHz and it sends an average 44100 samples per second at its
own clock which is slightly different from the device clock. Is it
right? If this is how it works, it means that the device has to do
some work to compensate the difference between the clock at the USB
controller level and at the device level. Is it still right?
Yes. As I understand it, the neither the USB spec nor the Audio Class
spec provide for expressing the device's sample clock to the host. I
think that with adaptive devices, they can provide feedback to the
host to give the host hints about going faster or slower, but I don't
recall if this is for host->device communication or just just for
device->host communication. I'd have to ask the guys working on the
USB driver to be sure.
As for whether or not you have to do any compensation, I'd have to
say that is really up to you. In most cases, all you really need to
do is have enough buffer space on the device to keep things moving
along. Provided the host doesn't go off into the weeds, that buffer
will generally be kept full enough to let your device play at
whatever speed it's local crystal dictates without any rate
conversion or whatever.
From the IN stream point of view, I've understood that the time is
measured each time the driver wraps around its ring buffer and that
this follows the rate at which data are provided by the device. Is
it right?
That's also true of the output side of things too.
To summarize my understanding (please, correct me if I'm wrong):
the OUT data rate is based on the host USB controller clock, and
the IN data rate is based on the device clock.
That's my understanding (hopefully one of the folks working on the
USB Audio driver will jump in an correct me, if it's wrong).
To be totally clear this it the USB clock of the host and the device
that we are talking about. The device's sample clock may or may not
actually drive the USB clock of the device. The USB spec doesn't say
one way or the other.
It sounds like you are trying to figure out how to approach some
problem. Perhaps you should go over what the problem is and we can
help direct you to a way to finding the solution.
Until now, I was making the assumption that IN and OUT data rates
were identical and I wanted to have a confirmation of it, and to
understand how the host controller and/or software could lock both
clocks. I understand that's it's not true because the clock can be
set to different values for each direction, and because they are
distinct. This is the problem I have now to solve because the
hardware is designed to run with the same sample rate for all audio
streams, IN, OUT, digital and analog.
Everything I've been talking about will generally "just work" if the
device is Audio Class compliant, which is why that's the way to go if
you are building the hardware.
If I put aside the option of a vendor specific driver, what are the
options that are still valid?
If the hardware is Audio Class compliant, you'll be using our Class
driver. As such, I don't know how much control you can get. It does
support plug-ins, but that's getting into an area I'm not that
familiar with. A good start would be to look at the USB Audio driver
that's in Darwin. You can see what it's doing.
At any rate, I'm still not that clear about the problem we're trying
to solve.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden