Re: AudioHardwarePlugIn, AUHAL, and Timestamps
Re: AudioHardwarePlugIn, AUHAL, and Timestamps
- Subject: Re: AudioHardwarePlugIn, AUHAL, and Timestamps
- From: Jeff Moore <email@hidden>
- Date: Mon, 23 Apr 2007 12:16:30 -0700
On Apr 22, 2007, at 1:18 PM, Chandrasekhar Ramakrishnan wrote:
I'm working on an AudioHardwarePlugIn. My implementation works in
HALLab and AULab, but I'd like to confirm that the approach is
correct and get some help on a couple of specific problems.
The plugin is a sort of glorified reflector driver -- it takes audio
from the client app, does a bit of processing, and then sends it to
another device. Being lazy, I've implemented it using an AUHAL in
the plugin to get/send audio to/from the wrapped device. There is a
configuration application that sends the processing parameters to
the plugin via a CFMessagePort, but no audio is transmitted -- all
the DSP happens in the memory space of the plugin.
The first question is: is this all kosher or should I redesign?
I have seen crash reports for crashes in people's HAL plug-ins that
were due to those plug-ins invoking the Component Manager in odd
contexts such as in a process that doesn't have a connection to the
Window Server. These crashes are not directly caused by the Component
Manager, the plug-in, or even the component that the plug-in was
trying to load. Rather, the crash happens when some other random
component isn't careful about checking the environment it is running
in and assumes something bad and crashes. These components get invoked
as part of the "kiss" the Comoponent Manager does to each component
when it is initialized in a process.
Technically, this would be a bug in whatever component is doing the
crashing, but in practice it limits the usefulness of components in a
HAL plug-in unless you can make some further guarantees about run time
environment of the process.
Assuming the design isn't fundementally flawed,
It is otherwise fine.
a follow-up question is how do I generate the timestamps to send to
clients of the plugin? AFAIK, it's not possible to get at the now,
input, and output timestamps the HAL gave the AUHAL. So I'm doing
the following:
output time -- timestamp provided by the AUHAL to my
AudioUnitRenderCallback
now -- AudioGetCurrentHostTime() and then use
AudioDeviceTranslateTime to get the corresponding sample time
input time -- output sample time - block size and then use
AudioDeviceTranslateTime to get the corresponding host time
(I've set kAudioOutputUnitProperty_StartTimestampsAtZero to false.)
Does this all sound good?
With kAudioOutputUnitProperty_StartTimestampsAtZero set to false the
time stamps AUHAL pass to you are supposed to be what the HAL passed
to it. To be 100% sure, you should make sure that there isn't any rate
conversion going on.
The only problem I see here is that the input time stamp calculation
is incorrect. Given the output sample time for a device, O, the IO
buffer size, B, the input and output safety offsets, Si and So, the
input sample time, I, would be calculated like this:
I = O - So - Si - 2B
As usual, you get the corresponding host time using
AudioDeviceTranslateTime.
As mentioned above, the plugin works with many applications, but
there is a problem in programs that only use the input side of the
plugin. E.g., if I use the AUHAL and turn off the output side, the
AUHAL input callback never gets called even though the plugin is
invoking its IOProcs. Any thoughts on why this might be the case?
I haven't the foggiest. Hopefully Doug will chime in and clear this up.
--
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