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: Mon, 14 Jan 2013 16:28:14 -0500
- Organization: Wavelength Audio, ltd.
- X_cmae_category: 0,0 Undefined,Undefined
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
Message: 2
Date: Mon, 14 Jan 2013 19:03:13 +0100
From: Mark Moore<email@hidden>
To:email@hidden
Subject: Core Audio maximum clock error
Message-ID:<email@hidden>
Content-Type: text/plain; charset=us-ascii
Does anyone know what the maximum clock error tolerance is for a USB audio-device?
I have a custom USB driver and a test app that generates sample data as a known sequence number pattern. The USB hardware has an external clock, asynchronous to USB and the Mac. The test app is directly bound to the HAL output (i.e. no varispeed).
If I run at 48KHz with no significant clock error, all is ok.
However, if I run with a +5% clock error (ie the hardware advertises 48KHz, but actually clocks at ~50KHz using adaptive rate control), I get a drop-out once per call to takeTimeStamp() in the driver. The drop-out appears to be the driver reading erased (non-existent) zero-valued samples, suggesting that the user-mode sample producer (pulling samples from the test app) is running too slowly. The drop-outs are quite long - up to ~40ms.
I have tried adjusting the setSampleOffset() and setSampleLatencyValues() in the Kernel driver, with no success. I have also checked that the timestamp generation for takeTimeStamp() is correct and tracks the actual clock speed.
Any suggestions as to what could cause this, or how to track down the problem? I can see what happens from the driver->device, and the app->HAL, but I can not see how the data is getting from the app to the driver's DMA buffer...
Many thanks,
-- Mark
_______________________________________________
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