Re: Threading Question
Re: Threading Question
- Subject: Re: Threading Question
- From: Mark Pauley <email@hidden>
- Date: Mon, 30 Jan 2012 14:20:40 -0800
You may want to try a non-blocking producer / consumer queue. Use a circular buffer, enqueue actions onto the queue from anywhere and only consume them from the audio thread. Your audio thread is a busy guy that needs to check for messages on some regular basis, and the rest of the time is spent processing the work he already has. Under no circumstances should you take a lock in the audio thread.
http://en.wikipedia.org/wiki/Non-blocking_algorithm
You'll have to use an atomic compare and swap algorithm to get rid of race conditions. "man atomic" for more info on what's available to you on MacOS / iOS.
good luck!
_Mark
On Jan 30, 2012, at 1:30 PM, ben kamen wrote:
> Hello,
>
> I have an iOS synth app and I am running into a problem that I think needs to be resolved through thread management or through some sort of locking system.
>
> I have an envelope generator, a c++ object, to which I call "attack()" "decay()" from an audio controller object. The envelope objects calls "decay()" and "sustain()" to itself within the render loop at appropriate times.
>
> I've noticed that the "attack()" and "release()" functions get called on different threads than the "sustain()" and "decay()" functions, which sometimes (though not terribly often) results in the messages occuring out of order, and causes notes to get stuck on.
>
> After some research my thinking is that I need a way to ensure that the audio controller only can call "attack()" or "release()" between render callbacks, or even better, in between processing each frame. Is there a design pattern or preferred method that can help me ensure that that will happen? A code example would be incredibly helpful.
>
> I realize this could also be a DSP question, but I'm pretty sure that is not my issue here. I'm interested in knowing what the proper way to avoid this kind of situation is.
>
> Thanks in advance!
>
> Ben
> _______________________________________________
> 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
_______________________________________________
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