Re: How long do render callbacks have to execute?
Re: How long do render callbacks have to execute?
- Subject: Re: How long do render callbacks have to execute?
- From: Brian Willoughby <email@hidden>
- Date: Fri, 12 Aug 2011 16:27:18 -0700
On Aug 12, 2011, at 15:39, Jonathan wrote:
Okay, that makes sense, but are the callbacks called in parallel?
In other words, is only one callback firing at a time? In the
example with two inputs into the mixer, does it fire one right
after another even though from a graph perspective they are peers?
In general, a processor cannot carry out any operations in parallel.
A dual core processor can do two things in parallel, but only if the
code is designed to create two threads and then schedules them to run
in parallel. Even then, it's quite difficult to force two pieces of
code to run precisely in parallel for many reasons, not the least of
which is that non-audio code is competing for the processor at all
times. In your example, you have three callbacks, and so those
surely cannot run in parallel on a single processor or even a dual
processor. Although quad-core processors are becoming common,
there's quite a bit of overhead involved in coordinating parallel
execution.
Instead, you'll find that the bulk of CoreAudio code executes
sequentially, just like any other code. I realize that the high
level concept is that these operations are peers - and in the world
of analog electronics they would certainly be 'calculated' in
parallel - but it's a fairly basic concept of programming that all
operations are reduced to sequential opcodes in the processor.
One thing is nearly certain: Apple's mixer does not create a separate
thread for each bus callback. That would wreak havoc with any
multithreading attempted by the AudioUnit host application.
I've been digging for that notification for a while now.. if you
happen to think of it, please let me know ;)
kAudioDeviceProcessorOverload
On Fri, Aug 12, 2011 at 2:13 PM, Brian Willoughby
<email@hidden> wrote:
On Aug 12, 2011, at 13:36, Jonathan wrote:
I have two callbacks that each feed into a mixer, and then I have
a render notify callback on the output of the mixer which feeds
into the remote IO unit.
How much time do I have in each of those call backs? I'm
assuming it's related to the IO Buffer duration.. so let's say I
have it set to .005 seconds. Does that mean that each of the
callbacks have .005 seconds to return, or is the duration divided
by the number of callbacks? For example, if there are three
callbacks in succession that each take .004 seconds to fill
buffers, is that going to meet the requirement or no?
The final audio is supposed to be continuous time, so if your IO
Buffer is .005 seconds then you must complete all audio processing
within that time, plus there must be some time left over for the
non-audio programming. Adding callbacks does not give you more time.
In your example with 3 callbacks, you probably only have about
0.001 seconds in each callback, with the remainder going to non-
audio code.
Related to that, is there a way to reliably detect when the boat
is missed, so to speak, so I can detect if the user is
experiencing skips?
There are two ways. First of all, there should be a CoreAudio
notification when you skip. You won't get this unless you
register for the notification callback, specifically, so look it
up in the documentation. I'm not sure whether iOS supports this
notification, but I assume it would have to just like OSX. Second
of all, the remote I/O unit should give you a time stamp on every
callback, and if these are not contiguous then you have suffered a
skip.
Brian Willoughby
Sound Consulting
_______________________________________________
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