Re: locks for AU rendering
Re: locks for AU rendering
- Subject: Re: locks for AU rendering
- From: Art Gillespie <email@hidden>
- Date: Tue, 8 Apr 2003 18:38:46 -0400
Hi Marc,
If it were me, I would use pthread_mutex_trylock in the Render() method
instead of pthread_mutex_lock.
The lock variant will block the calling thread until the lock is
released, while the trylock version will return immediately with EBUSY.
My strategy in Render() is to clear the output buffers if the trylock
returns EBUSY and stuff kAudioUnitRenderAction_OutputIsSilence in the
action flags.
This will keep you from blocking the audio thread should one of your
state changes take an unacceptably long time.
Best,
Art
>>0xBA
On Tuesday, April 8, 2003, at 05:00 PM, Marc Poirier wrote:
Hi. I am working on an AU that performs pretty hefty state change on
the
DSP settings when loading presets, so I've decided that I would be
better
off adding locks to my AU for thread safety. But I'm not very
educated on
the different lock APIs in Mac OS X and their performance issues
(which of
course are important with realtime audio).
My needs are pretty simple, though. I have data that I write to when a
preset is loaded and that I read from while rendering audio. So I
need to
lock the data before each of those operations and unlock it
afterwords. I
can't really use time-outs because these things need to happen, so I'm
using thread-blocking locks.
Currently I'm using pthread mutexes. I have one of these in my AU
effect
component class:
pthread_mutex_t pmut;
and then in my plugin's constructor I do this:
pthread_mutex_init(&pmut, NULL);
and then in the destructor I do this:
pthread_mutex_destroy(&pmut);
and then before loading a preset or rendering an audio slice I do this:
pthread_mutex_lock(&pmut);
and then, after either of those things are finished, I do this:
pthread_mutex_unlock(&pmut);
Is this considered to be an okay way to go about this? Or should I be
taking another strategy? Any advice is very welcome. This is
something
with which I don't have a lot of experience.
Thanks,
Marc
_______________________________________________
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.
_______________________________________________
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.