Re: Multi-threaded render
Re: Multi-threaded render
- Subject: Re: Multi-threaded render
- From: Craig Hopson <email@hidden>
- Date: Mon, 7 Aug 2006 13:24:19 -0700
True. I had forgotten about it because we could not use it - it is
available for Tiger (and beyond). So, we needed to roll our own...
But really, I'm not bitter about that... ;-)
-Craig
On Aug 7, 2006, at 12:08 PM, William Stewart wrote:
We ship an AU that does exactly this:
aufc defr appl - Apple: AUDeferredRenderer
Basically, its job is to get its input on a different thread than
it's AudioUnitRender is being called on. You have properties to
control the various behaviours of this AU - have a look in
<AudioUnit/AudioUnitProperties.h>
Bill
On 05/08/2006, at 12:41 PM, Ethan Funk wrote:
Currently, I have an audio application, like many, where multiple
audio sources are mixed together by a custom mixer and delivered
to the HALoutput AU. All is well except, in the interest of
efficiently using multi-processor systems, I would like to move
away from the single thread render approach, and have each mixer
input run in it's own thread.
For example, the HALOutput AU would callback to my mixer in the
usual coreaudio rendering thread. My mixer would then wake a
render thread associated with each of it's inputs and block the
calling rendering thread until all the input threads have buffers
ready for my mixer. My mixer would then continue executing the
coreaudio render thread where it would mix the input results and
return the final buffer to the HALOutput AU. All this should be
simple to implement, however, I believe that rendering threads
have some special realtime properties, and I have no idea how to
create such threads for each of my mixer inputs. Likewise, I
don't understand threading on OS X well enough to know what
scheduling problems I may encounter. Any ideas where I can go to
learn more about this sort of thing?
My ultimate goal is to move each mixer input render in it's own
thread so that concurrent processing COULD occur when there is
more than one processor available. It would appear that as things
stand with the single thread approach, each mixer input chain must
be rendered one at at time. The total render time is the sum of
the time required to render from all the inputs together. If I
have a heavy processing load (a lot of AU effects in the input
chains), even with multiple processors, the whole render process
will only use one of the available processors. If I have two or
more processors, it would be nice to have each processor work on
different renders to improve the chance that it would all get done
in time to deliver the results to the HALOutput AU.
Any one else doing anything like this? Am I going down a wrong
road here?
Ethan...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
--
mailto:email@hidden
tel: +1 408 974 4056
______________________________________________________________________
____
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
______________________________________________________________________
____
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40redrocksw.com
This email sent to email@hidden
***************************************************
Craig Hopson, Managing Partner
Red Rock Software, Inc.
10 West Broadway, Suite 850
Salt Lake City, UT 84101
office: 801.322.4322 x103
cell: 801.949.3526
http://www.redrocksw.com
_______________________________________________
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