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

[Stephen Sinclair]

On Thu, Feb 24, 2011 at 4:04 PM, Morgan Packard
<morgan at morganpackard.com> 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

In general I'd recommend keeping your STK code in one place, and using
a non-blocking message queue for communication.

That said, calling keyOn() just sets a couple of variables (the target
velocity and state=attach) that aren't dependent on each other.  I
doubt it would cause you any grief.

If ADSR is getting NaN's it's more likely a numerical error
somewhere.. can you report on the other values of ADSR's state?
(attack time, decay time, etc..)

There's one potential issue I see, looking at ADSR.cpp: If
setAttack/Decay/ReleaseTime are called with time=0, it will result in
a division by zero.  Not that I think STK should necessarily waste
cycles checking for this, you should instead make sure these functions
are not called with time=0 in your code.  But I don't know if that's
the issue here.

Another thing that can happen is that NaNs can work their way into
your own code somewhere and then you can set them as parameters
accidentally, corrupting the internal states of STK objects.  So in
general, check your inputs to make sure they are valid.  (Perhaps do
this consistently everywhere when you compile in "debug mode", for
testing purposes, and leave out the checks in "release mode"
configuration.)

Steve