• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: locks for AU rendering
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

  • Follow-Ups:
    • Re: locks for AU rendering
      • From: Marc Poirier <email@hidden>
  • Prev by Date: Re: locks for AU rendering
  • Next by Date: audio text book recomendations?
  • Previous by thread: Re: locks for AU rendering
  • Next by thread: Re: locks for AU rendering
  • Index(es):
    • Date
    • Thread