Re: Multi-threaded render
Re: Multi-threaded render
- Subject: Re: Multi-threaded render
- From: Chandrasekhar Ramakrishnan <email@hidden>
- Date: Mon, 07 Aug 2006 12:53:28 -0700
> On Aug 5, 2006, at 1:41 PM, Ethan Funk wrote:
> > 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.
You shouldn't implement it that way -- if you block your render thread
waiting for data from the inputs, your audio *will* glitch.
Craig Hopson schrieb:
> 1. Yes, we are doing something similar... ...but different. We've
> implemented an event driven processor which feeds a ring buffer. The
> CA pull is on the output side of the buffer, the processor(s) feed
> the input side.
This is what I do as well. Take a look at CABufferQueue.{h, cpp} in
/Developer/Examples/CoreAudio/PublicUtility/AudioFile-new/
.
It's great piece of sample code and worth spending a bit of time
understanding. You can implement your processing as a subclass of
CAPullBufferQueue.
You need to implement ProcessBuffer in your subclass to generate a
buffer worth of audio in the secondary thread and call
CAPullBufferQueue::PullBuffer() in the render thread; the superclass
will take care of creating a thread with the correct
attributes/priorty as well as recycling buffers as they get used up by
the render thread and calling for more samples on the secondary thread
as necessary.
- sekhar
--
C. Ramakrishnan 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