audio computation and feeder threads
audio computation and feeder threads
- Subject: audio computation and feeder threads
- From: Kurt Bigler <email@hidden>
- Date: Fri, 28 Feb 2003 20:10:12 -0800
I am trying to glean from all the information which has gone by on this list
what I need for a general plan for thread design in my app. I would like to
focus for the moment on the case of audio output only, when the audio is
being synthesised algorithmically. I would specifically like to include the
possibility of multiple IOProcs being active to support multiple output
devices running at once.
The topic of feeder threads has come up a lot, although I believe usually
this has been in connection with playing audio files.
I am trying to decide when it is a worthy thing to use a feeder thread in
connection with an IOProc thread. The following thoughts come to mind as I
try to put together my ideas on this, and I would appreciate feedback.
First of all, the mere fact of outputting synthesized audio apparently does
not in itself appear to constitute a reason for having a feeder thread. I
am assuming (though maybe I am wrong) that Apple's audio units do not have
any multi-thread decoupling/buffering going on in them - particularly audio
units that do synthesis from midi would be the issue here. Can I assume
that the DLS Synth (which I know _absolutely_ nothing about, yet need to use
here as an example) does its synthesis right in the IOProc thread? If yes,
then can I assume that this is therefore an "ok thing"?
So, I can think of several reasons to use a feeder thread (together with
appropriate buffering and consequent additional latency) to feed synthesized
audio to an IOProc thread:
(1) to keep blocking calls out of the IOProc
(2) to buffer against irregularities in the synthesis process, possibly
allowing early detection of a processing lag, allowing corrective responses
(e.g. reduced precision) to be applied graciously rather than having to be
applied instantly (e.g. note dropping)
(3) to buffer against irregularities in system performance, such as some
"randomness" in the scheduler together with the unpredictable nature of the
demands put on the scheduler
(4) to buffer against much nastier things like thread-performance
inter-dependencies caused by caching issues. For example, suppose two
memory-hungry threads (possibly even two different IOProcs) happen to get
scheduled in parallel on 2 cpus, with the result that performance drops
sharply in both because of collisions in use of memory. It might have been
better if they had been scheduled serially on the same cpu. But I assume
there is nothing in the scheduler that could recognize and avoid these kinds
of situations, even heuristically.
(5) perhaps - to make good use of multiple processors on the system when
they are available. In this case I am not so much thinking of things like
cache problems, but rather how to balance the synthesis computations across
all available processors, while not interfering with IOProc performance.
For example I could spawn a bunch of synthesis feeder threads, possibly more
threads than there are processors, so that the scheduler is left with lots
of flexibility - in case other system loads can not be distributed evenly
between the processors, my own threads can take up the slack wherever it
exists.
(6) to get back that extra 10% of the 90% that the HAL will allow, as per
Jeff Moore's message of 2/26/03 6:02 PM:
>
The HAL has a hard limit of roughly 90% CPU usage as measured against
>
the deadlines it calculates internally before it will put you in the
>
penalty box and issue kAudioDevicePropertyOverload notifications (this
Am I basically on the right track in my thinking here? Is that just about
it? Are there any other compelling reasons for using a feeder thread?
Item (5) is particularly of interest to me right now. I first tried
improving performance on a 2-processor machine with 2 output devices active
by doing synthesis independently in each IOProc thread. I found that in
some cases I get a 50% increase in performance, and in other cases no
reliable improvement at all. In particular my altivec-optimized synthesis
gets no reliable increase, and in fact sometimes a sharp drop. This is in
spite of attempts to keep memory use to a very small minimum, although I
can't prove that there were not many scattered accesses to memory that did
not happen to collide badly in their timing on 2 processors. Any not to
dwell on these details here.
So, if I am basically on the right track with my thinking, it is fair to say
that optimized audio synthesis directed towards multiple IOProcs should
probably always use feeder threads, if the goal is to be able to get as
close as possible to saturating the CPU?
And if so... would it be useful - and possible - to create one or more audio
units whose sole purpose is to decouple its pulling callback from its
rendering callback? Would such an audio unit make it possible for audio
developers to deal with a much broader set of requirments without having to
develop so much in-house expertise on thread management? I envision an
audio unit that permitted sufficiently flexible control over buffering and
latency (and thread priority?) that almost all audio application thread
management could be vastly simplified.
Note that this technology would also make it possible for an output audio
unit that could span any number of output devices, possibly running at
different sample rates. Obviously I'm glossing over a lot of detail here -
but I'm actually hoping that someone at Apple will do this in which case all
the details will be take care of!
Thanks,
Kurt Bigler
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.