I’m not entirely sure how this is related to process priority queues & handling of such. I don’t think anything about my suspicions towards the sound code would change whether pre-empted process go to the back of the queue or not; in this case the sound process pre-empts the other process, does some stuff that happens to be assuming an instvars is not nil, and if the pre-emption occurs at an inopportune moment it turns out that the instvar has been set to nil by #sustainEnd: for a short period.

So far as I can tell we’re not involving any yields to same-priority processes. It’s just some code that makes an assumption that makes an ass of it, as they so often do.

I think that either not fudging loopEndMSecs or possibly guarding the usage of it in computeSlopeAtMSecs would solve this. Or maybe a cleaner way to ‘stopGracefully’. 

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
People who deal with bits should expect to get bitten.