Re: Core Audio maximum clock error (Mark Moore)
Re: Core Audio maximum clock error (Mark Moore)
- Subject: Re: Core Audio maximum clock error (Mark Moore)
- From: Gordon Rankin <email@hidden>
- Date: Wed, 16 Jan 2013 12:05:33 -0500
- Organization: Wavelength Audio, ltd.
- X_cmae_category: 0,0 Undefined,Undefined
Mark,
If you have your own driver, then maybe you want the hardware to show an
enumeration that is non audio specific and therefore you can stream data
as required to make this work. I am not so much an expert in coding in
the lower levels as understanding what a USB Audio device is, more on
the hardware endpoint side of the equation.
- is there a limit on the maximum clock error that CoreAudio supports?
If you set your device up an Adaptive endpoint and are using CoreAudio,
then the maximum clock error would = 0. As you would have to synchronize
your clock to match the flow of the data sent from the computer to act
as flow control.
- is takeTimeStamp() sufficient to synchronise user/kernel space clocks?
I would wonder if that is doing anything, but again, not the person to
ask that question.
If you do a sample rate change the only thing in my mind that it would
be doing is restarting the stream over again and resetting the buffers
for which your device is going to start over again.
This is what I would suggest you do for a simple fix. I would change
from Adaptive to Asynchronous at the endpoint. @ the endpoint calculate
your samples in the buffer and create a feedback pipe to send back to
the computer so the stream stays active and you don't have under or
overruns in the data flow to your device.
Thanks,
Gordon
On 1/16/13 11:36 AM, Mark Moore wrote:
Hi Gordon,
The driver is using implicit feedback. It is generating the correct output rate, based on USB traces and based on debug code that logs that output sample rate. The clock is propagated to the application HAL layer via takeTimeStamp(), and the timestamps appear to be accurate (code based on AppleUSBAudio's USB timing).
However, once per IO buffer wrap, the HAL seems to skip ahead as if catching up, though no actual errors are logged in the HALLab telemetry (which, incidentally, seems to be missing from Xcode 4...).
I seem to be able to work-around the problem in the USB driver by calling IOAudioEngine::hardwareSampleRateChanged() with the new calculated rate. Doing so causes a brief pause in the stream so I only want to do this as a last resort.
So I guess the questions are:
- is there a limit on the maximum clock error that CoreAudio supports?
- is takeTimeStamp() sufficient to synchronise user/kernel space clocks?
Thanks,
-- Mark
On 14 Jan 2013, at 22:28, Gordon Rankin <email@hidden> wrote:
Mark,
I do a ton of async USB audio stuff.
Mark, if you advertise 48Khz and Adaptive then it is up to you to create a PLL or other moving Master Clock that matches the computer. That is how the flow control for adaptive works. What you want to do is either enumerate at 50KHz & adaptive or use Asynchronous USB Audio (see class 1 specification on USB.org) and make sure your feedback pipe fills at a rate that keeps your buffers filled at the endpoint. If you have a fixed Master Clock = 50KHz sampling then Async is your best bet.
Thanks,
Gordon
Wavelength Audio
_______________________________________________
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