Re: in & out Callbacks
Re: in & out Callbacks
- Subject: Re: in & out Callbacks
- From: Lubor Prikryl <email@hidden>
- Date: Mon, 14 Feb 2005 23:04:51 +0100
Hello Jeff and others who are interested,
On 14.2.2005, at 21:00, Jeff Moore wrote:
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.
Actually, I don't try to synchronize audio threads. But I have some
suspicion that the thread handling I/O for USB (if it were any) is not
synchronized properly with the audio thread. Is it possible?
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?
Probably not. Input and output callbacks from ONE device run in ONE
thread, (I dont list threads I have created, MIDI and event loop)
Thread 1a
#0 0x00020560 in InputAudioCallback(unsigned long, AudioTimeStamp
const*, AudioBufferList const*, AudioTimeStamp const*,
AudioBufferList*, AudioTimeStamp const*, void*) at RTHAL.cpp:1065
#1 0x9072360c in IOADevice::CallIOProcs(AudioTimeStamp const&,
AudioTimeStamp const&, AudioTimeStamp const&)
#2 0x90723a60 in HPIOThread::PerformIO(AudioTimeStamp const&)
#3 0x90722c14 in HPIOThread::WorkLoop()
#4 0x9073919c in HPIOThread::ThreadEntry(HPIOThread*)
#5 0x907391e0 in CAPThread::Entry(CAPThread*)
#6 0x900246e8 in _pthread_body
the same thread 1b
#0 0x0001f64c in OutputAudioCallback(unsigned long, AudioTimeStamp
const*, AudioBufferList const*, AudioTimeStamp const*,
AudioBufferList*, AudioTimeStamp const*, void*) at RTHAL.cpp:853
#1 0x9072360c in IOADevice::CallIOProcs(AudioTimeStamp const&,
AudioTimeStamp const&, AudioTimeStamp const&)
#2 0x90723a60 in HPIOThread::PerformIO(AudioTimeStamp const&)
#3 0x90722c14 in HPIOThread::WorkLoop()
#4 0x9073919c in HPIOThread::ThreadEntry(HPIOThread*)
#5 0x907391e0 in CAPThread::Entry(CAPThread*)
#6 0x900246e8 in _pthread_body
Thread 2
#0 0x900074c8 in mach_msg_trap
#1 0x90007018 in mach_msg
#2 0x90191700 in __CFRunLoopRun
#3 0x90195e8c in CFRunLoopRunSpecific
#4 0x90732f80 in HALRunLoop::OwnThread(void*)
#5 0x907391e0 in CAPThread::Entry(CAPThread*)
#6 0x900246e8 in _pthread_body
and Thread 3
#0 0x900074c8 in mach_msg_trap
#1 0x90007018 in mach_msg
#2 0x90191700 in __CFRunLoopRun
#3 0x90195e8c in CFRunLoopRunSpecific
#4 0x901ff328 in CFRunLoopRun
#5 0x077142bc in
AVS::DestroyAVCDeviceController(AVS::AVCDeviceController*)
#6 0x900246e8 in _pthread_body
Jeff, my questions are here:
- What the latter two threads do?
- Are the two Callbacks 1a and 1b always guaranteed to be called
exactly alternating i-o-i-o-i-o-i-o... if running in one thread?
- For the USB class driver, 1a and 1b are TWO threads just as for
physically different devices, so should I synchronize them manually?
The third question implies:
- How can I handle I/O using HAL Output AU, when input and output are
divided in two devices for the USB class driver?
I think, depending on these answers I will have or won't have to follow
your suggestions below.
Thanks
Lubor
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:
email@hidden
This email sent to email@hidden
_______________________________________________
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