Re: in & out Callbacks
Re: in & out Callbacks
- Subject: Re: in & out Callbacks
- From: Jeff Moore <email@hidden>
- Date: Mon, 14 Feb 2005 12:00:26 -0800
Have you looked for the cause of your glitching? If you haven't pinned
it down precisely, you probably should because 9 times out of 10 it's
not what you think it is, especially if you are trying to synchronize
multiple threads.
That said, I'm a bit puzzled by what you are trying to accomplish. It
sounds to me like you are trying to take input received from one
device, process it, and put it out on another device, which
necessitates synchronizing the two IO threads. Yes?
First off, I'd look very closely at how you are synchronizing the
threads. If there are mutexes involved, I'd check them thoroughly to be
sure that the IO thread can never, ever block on them. Otherwise, you
will glitch.
Next, as you surmise, you can't directly control the phasing of the two
IO threads with AudioDeviceStart(). You need to use
AudioDeviceStartAtTime() to do that. This allows you to set things up
so that the input device's IO thread runs out of phase with the output
device's IO thread by making them start at particular times using IO
buffer sizes that represent the same amount of time. This allows you to
be sure that the input is delivered before the output.
The only problem you'll have with that scheme is drift over time if the
input device is not synchronized with the output device in hardware.
The drift will slowly shift the phase between the input and output
threads until they eventually coincide. The speed at which this happens
depends on the rate scalar between the devices. The only way to fix it
would be to periodically stop and restart things.
On Feb 12, 2005, at 9:53 AM, Lubor Prikryl wrote:
Hi,
My app is processing a stack of effects. I did the following:
- in the input callback I copied data from mBuffers[].mData to my
buffers
- in the output callback I processed the data and copied them back to
mBuffers[].mData
On certain systems generally with higher CPU load (but NOT overload)
my application clicks and pops from time to time.
To fix it, I changed to this:
- in the input callback I do nothing
- all the work was done in the output callback
My questions:
- What is better? (I think the second, but it cannot be used
generally)
- For the first approach, is it guaranteed that callbacks are called
exactly i-o-i-o-i-o-i-o-i-o-i-o... for one device? (I perform
checking, it actually seems to be regular)
- The second approach can't be used with USB class driver or with two
externally synced devices unless I would establish circular buffers
and increase latency. I expect some non-regular alternating here,
correct?
- If I would replace the AudioDeviceAddIOProc based HAL i/o by an
AudioUnit i/o, I would get to the bad situation with the usb class
compliant driver and externally synchronized devices, I would open
two AUs to handle, but only one i/o AU is allowed per one Graph.
Thanks for a hint
Lubor
--
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