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: philippe wicker <email@hidden>
- Date: Wed, 21 Dec 2005 11:52:38 +0100
On Dec 21, 2005, at 2:04 AM, Jeff Moore wrote:
First of all thanks for your explanations, they greatly help me :)
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.
I've downloaded the AppleUSBAudio project from the Darwin repository
and I've started to study the code.
At any rate, I'm still not that clear about the problem we're
trying to solve.
My first concern is to debug the hardware involved in the audio
processing. This hardware is quite complex and I've planned to
proceed step by step. My first step is to validate the audio path
between the host computer (Mac/PC) and the device. My test would have
been simpler and could be run automatically if both clocks were locked.
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
audio is provided by the host computer at a rate based on the host
USB controller clock. This audio is consumed at the device level at a
rate based on the device audio clock. These clocks are unrelated. If
the user chooses - say - 96KHz for the input stream in AMS and - say
- 44.1 for the output stream, then the whole audio processing in the
device is made at 96 KHz (DACs and ADCs clocks are set to 96KHZ and
the DSP software is configured accordingly). I therefore need to
perform - at the device level - a SRC from 44.1 to 96KHz on the synth
input stream. Even if the user chooses the same *nominal* sample rate
for input and output, I still have to deal with the fact that actual
values are slightly different and are surely drifting depending eg on
the temperature. Quartz are given with a precision of a couple of
10-6 which leads to a cumulated error of about .5 10-6 which means
that when the device is expecting - say - 200000 samples it really
receives some number between 199999 and 200001. So I have to add/
remove a sample from time to time or to do a more sophisticated
"adaptive" SRC similar to the one which is made by an AUVarispeed. I
wouldn't have had to do this processing if both clocks were locked.
Hence the original question.
--
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
_______________________________________________
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