Re: locks for AU rendering
Re: locks for AU rendering
- Subject: Re: locks for AU rendering
- From: Marc Poirier <email@hidden>
- Date: Wed, 9 Apr 2003 09:48:21 +0200 (CEST)
Thanks Art, I like that idea. I'm using that now, with just a slight
variation where, if trylock fails, I simply copy the inputs to the
outputs, so that frame passed through dry/unprocessed. This isn't totally
ideal or smooth, but given that the only time I need to do this is when I
new preset is loaded and given that that is going to cause some sudden
changes and unsmoothness anyway, it's really a minor issue.
Thanks again,
Marc
On Tue, 8 Apr 2003, Art Gillespie wrote:
>
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
_______________________________________________
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.