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: Wed, 21 Dec 2005 12:30:34 -0800
On Dec 21, 2005, at 2:52 AM, philippe wicker wrote:
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.
True. The USB Audio Class spec didn't seem to have synchronization in
mind when it was drawn up. I've heard that the 2.0 spec does a much
better job at it.
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.
Since it seems like you have some degree of control over the
firmware, couldn't you make it so that the input and the output
always have the same rate? In other words, when one changes, the
other changes to match. At least, then the nominal rates would be the
same which will help alleviate a lot of issues.
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.
Yup. This is all totally true. The HAL does this exact operation as
part of it's aggregate device support when the aggregate is using
software synchronization.
Presumably, you can't control the rate of the DAC/ADC's on this
hardware? That's probably the best way to go, if you can. Otherwise,
you'll need to do what you described to make the rates match up.
--
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