I must confess. I don't know Jack. So... Before we, heh, re-implement ChucK and RtAudio, I would like to know the following, at least: 1. Why is the mutex actually bad? More specifically, how exactly does it cause Jack to fail or zombie? ChucK does not call RtAudio from multiple threads, so the mutex shouldn't be blocking at all. 2. If the concern is things taking too long in the callback, how does putting audio synthesis in the callback help? The current scheme has the audio pre-computed before the callback. Putting the most time consuming part of ChucK inside the callback will more likely delay the callback. Dave, you said that replacing blocking I/O with computing audio in callback makes things robust, regardless of load. How does Jack know the difference between the callback blocking versus just taking a long time computing audio? I am clearly missing something here. Related question: 3. Under what conditions does Jack decide to boot a process? 4. If our blocking scheme is the problem, then why doesn't sndpeek work? The callback just copies the input buffer and returns. Confused, Ge!