Re: timestamps for usb audio device
Re: timestamps for usb audio device
- Subject: Re: timestamps for usb audio device
- From: Jeff Moore <email@hidden>
- Date: Wed, 12 May 2010 15:47:24 -0700
On May 12, 2010, at 3:44 PM, Jeff Schindler wrote:
> On May 12, 2010, at 3:06 PM, Jeff Moore wrote:
>
>>> HALLab does detect some bad timestamps, but those detections don't necessarily correlate with the glitches we are detecting (both audibly and via a scope). First off, should the reported bad timestamps in HALLab (red lines) correspond to audible glitches and will HALLab necessarily report all bad timestamps generated?
>>
>> No. Sometimes the glitches are slight enough to not be heard. The HAL will also internally correct for certain kinds of bad time stamps.
>
> Is the opposite also true - that an audible glitch will not show as a "bad" timestamp in HALLab? I suppose that could either point to another possible source for a given glitch, or that HALLab doesn't see a bad timestamp as bad...
Yes. That is possible too. There are a lot of non-timing related reasons for a glitch. For example, if the glitch is already in the audio data when the app puts it into the output buffer.
>>> Secondly, is the most likely culprit of our glitchy audio timestamp related and, if so, what things might we try to correct it? Thanks for any help.
>>
>>
>> You really need to be generating your time stamps based on the interrupt times for the USB frame edges. Otherwise, you will have more noise than signal in your time stamps from the scheduling latency. If I remember right, the driver for the controller stashes the host time for the frame edge somewhere in it's data structures. I'm not a USB expert, so you'd probably need to dig through the documentation and headers to find out more info about where to look for the value.
>>
>> But once you know the time for the frame edges, you can build up an interpolator to get a good estimate for the time when the ring buffer wraps from the middle of a frame. Of course, if you can arrange to have your ring buffer occupy a whole number of USB frames, so much the easier.
>
> Thanks for confirming what we suspected. We've already started going down this road, using the AppleUSBAudio driver as a model, so we'll continue with that. Thanks for the help.
No worries.
--
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