Re: Correctly implementing TranslateTime and GetNearestStartTime in HAL user-land plugin
Re: Correctly implementing TranslateTime and GetNearestStartTime in HAL user-land plugin
- Subject: Re: Correctly implementing TranslateTime and GetNearestStartTime in HAL user-land plugin
- From: Jeff Moore <email@hidden>
- Date: Wed, 18 Nov 2009 11:09:12 -0800
The time stamps for any audio device correlate the device's sample time with the host's timebase (which is mach_absolute_time) and provide a rate scalar to describe how much faster/slower than nominal the device is running. This is pretty fundamental to how things work. You might want to track down my WWDC talks from early in MacOS X's existence (2001 or 2002 would probably be about right). In those talks, I go into excruciating detail about how timing works on the system.
At any rate for IOAudio-based devices, the way it works is that the hardware is looping around a ring buffer. Every time it wraps around, it provides the HAL with a time stamp that says what the host time was at for the first sample in the ring buffer. The HAL uses these time stamps as the inputs into the HAL's clock that smooths out the jitter and provides accurate estimations for the times between the time stamps the driver provides.
AudioDeviceTranslateTime() is pretty much a direct code path to the HAL's clock. It applies the projection in the clock to provide the request time translation. For example given a sample time, it will provide the corresponding host time.
AudioDeviceGetNearestStartTime() allows a client to ask the device what the most convenient start time is. The answer a device provides depends on the device and it's characteristics. For example, the IOAudio support in the HAL can start on any sample edge. As such, it will return the time the client passed in provided that there are no active IOProcs and the requested time is at least two IO buffers worth of time in the future.
Note that both of these functions only work when the hardware is already running.
Also note that the code for both of these functions that is in the SampleHardwarePlugIn example, SHP_Device::TranslateTime() and SHP_Device::GetNearestStartTime(), both implement what I just described. The only catch is that the SHP_Device class isn't attached to any real hardware so it always runs at the nominal rate. It does this using the member variable, mAnchorHostTime, to provide the beginning of the projection and it always computes the number of host ticks per sample using the nominal sample rate.
Even if this way of doing the computation doesn't work for your setup, it at least should provide a good guideline to what the result of the math is supposed to provide.
On Nov 18, 2009, at 4:48 AM, Stéphane Letz wrote:
> Our HAL user-land plugin does not really implement TranslateTime and GetNearestStartTime timing functions, and this may explain issues we have with some applications (like Flash player where video and audio get de-synchronized and/or audio play glitchy...). We cannot really start with the code that is part of SampleHardwarePlugin, and what has to be done in those 2 functions is not so clear in the code...
>
> Is there any kind of general explanation of the purpose of those timing functions and how to implement them the "right way" ?
--
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