Core Audio maximum clock error
Core Audio maximum clock error
- Subject: Core Audio maximum clock error
- From: Mark Moore <email@hidden>
- Date: Mon, 14 Jan 2013 19:03:13 +0100
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