Audio thread misbehaviour?

Okay, I’ve got my own audio mixing system in exult. Under the old
system, I had two classes of audio data. One was mixed immediately into
a buffer ring. The other was a file-descriptor from a forked subprocess.
Each time SDL’s audio thread interrupted for more data, I’d give it the
next buffer off the ring, mix in whatever data was available from the
descriptor, and spin the ring to the next position.

Fine, but that descriptor code made portability a little awkward. Enter
the producer/consumer buffer. The subprocess is handled with
popen()/pclose() in a separate thread, and the mixer and producer thread
share the buffer. SDL_mutex’es are used to protect the contents of the
buffer, as well as all the data-structures holding it. Good so far. The
buffering algorithm’s been torn out of some fairly well tested code. So,
the new structure is: Each time SDL’s audio thread interrupts for more
data, hand it the next buffer off the ring, spin the ring, and mix in
whatever’s available from the PCB up to the required length.

Now, rather oddly, this blows up in my face, but in an odd way.
I expected it to break first time. Much code changed. Thing is, it
didn’t. The audio came out beautifully. Except (usually) every other
audio track (fed through the PCB). Initial feel seems to be that SDL’s
audio thread (when we unpause it) is suddenly calling the audio feeder
at many times the usual rate. When we run out of data again, and pause
it, then unpause it, it behaves. Rinse and repeat, and it misbehaves

Can’t manufacture a small test case, yet. Too much dependant code. :confused:

Anyone seen anything like this? (Linux+gcc2.95.2)