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, 19 May 2010 17:36:17 -0700
The OoB event in the telemetry signfies a time stamp whose host time is more than a millisecond into the future. When the HAL sees a time stamp like this, it substitutes a time stamp that is more in line with expectations.
The Reset event signifies a time stamp whose sample time is not exactly one ring buffer later than the previous time stamp's sample time. The HAL resynchs for this kind of problem. Note that for an IOAudio driver, this usually means that the loop count in the status block was incremented too far.
As for glitches at one buffer size vs. another, I presume that you are referring to the IO buffer size in the HAL's clients. At any rate, these issues are probably related to the fact that your driver is still not delivering good time stamps.
--
Jeff Moore
Core Audio
Apple
On May 19, 2010, at 11:56 AM, Jeff Schindler wrote:
> That all makes perfect sense. I'm finding now that I can get into a state where we are virtually glitch free at certain buffer sizes, which I haven't seen before. Without going into detail on my test setup, I essentially restart the test and can get into this glitch-free mode (there are some, but they are very few). I do see that HALLab is still periodically reporting bad timestamps when I get into this mode - but they are not the "early" type that I described earlier, but rather appear in pairs as in the attached. It looks as though HAL is reporting the reset you described earlier, but I'm not sure - do you have any insight on that? Just to be clear, these reported bad timestamps do not correlate with an audio glitch and I do not see any of the "early" timestamps reported in this mode. At small buffer sizes, I do get glitches, but they are not periodic (ie more random). When I am seeing the periodic glitches (roughly every 2.1 seconds or so), they are consistent at any buffer size. Any idea why I would see the periodic glitch in one instance and not in this other?
>
> <hallab2.tiff>
>
> On May 19, 2010, at 12:04 PM, Jeff Moore wrote:
>
>> That error means that a clock that is supposed to be delivering time stamps representing a relatively constant rate (which USB devices are by default) has delivered a time stamp that is more than a millisecond earlier than what the HAL was expecting based on previous time stamps.
>>
>> In other words, the HAL is flagging that time stamp as being significantly out of line with what had come previously. When this happens, it cause the HAL to rsynch to the new time line anchored by this time stamp. This often, but not always, will result in a glitch.
>>
>> --
>>
>> Jeff Moore
>> Core Audio
>> Apple
>>
>>
>> On May 19, 2010, at 7:52 AM, Jeff Schindler wrote:
>>
>>> Hi Jeff - we ended up mirroring the code from the AppleUSBAudio driver for timestamp generation and seem to be getting fairly decent timestamps now, but we are seeing a periodic glitch (just over every 2 seconds). I'm trying to glean some info on the glitch from HALLab - it is correlating with the glitch by reporting a bad/early (red) entry with the same period, but I'm having trouble placing any meaning on its output. We get entries like enclosed - can you help with deciphering that?
>>>
>>> Thanks,
>>> Jeff
>>>
>>> <hallab.tiff>
>>>
>>>
>>> On May 12, 2010, at 3:06 PM, Jeff Moore wrote:
>>>
>>>> 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.
_______________________________________________
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