[Stk] could my badly-written multithreaded code be related to ADSR's value_ and releaseRate_ having NaN as a value?

[Gary Scavone]

Hi Morgan,

I've gotten a few bug reports regarding the ADSR class lately, one related to setting a sustain level of zero and the other related to an incorrect decay time setting if the sustain level is not 1.  I haven't had time to combine both fixes in a new class.  But I haven't heard about any NAN-related issues.

I don't necessarily see a problem related to calling keyOn() and tick() from different threads.

--gary

On 2011-02-24, at 4:04 PM, Morgan Packard wrote:

> Hello,
> 
> I'm currently calling ADSR::keyOn from my UI thread, and calling ADSR::tick() from an IO callback thread.
> This is bad, right? This class is not thread-safe, and these methods both need to be called from the same thread, correct?
> 
> My application has a very occasional, impossible to reproduce bug which results in all audio output completely stopping. I just managed to see the bug with the debugger hooked up, and traced it back to NaN's originating from ADSR. My guess is that ADSR was thrown in to this faulty state by a collision between my two threads. Anyone have any other ideas of what it could be, or does my hypothesis sound like a good one?
> 
> Is there any preferred way to trigger an ADSR from an external thread? Seems to me that a message queue approach may be the easiest, and won't result in any blocking of the audio thread.
> 
> thanks,
> 
> -Morgan
> 
> -- 
> ================================
> Web:
> http://www.morganpackard.com
> 
> Music/Art:
> Latest album: Moment Again Elsewhere
> iOS app Thicket available on iTunes store.
> ================================
> 
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk