Apparently, if you use playwave and specify that a sound should loop (-l
flag), there is a small, but repeatable chance that you will call
Mix_Playing() while the sample has completely mixed to the audio device
(so that mix_channel[0].playing == 0), but before it has restarted the
loop (mix_channel[0].looping > 0). In such a case, a channel will be
reported to have halted when in fact it is still playing.
The other workaround is to use the Mix_ChannelFinished() function, which
always reports accurately. The attached patch will fix the polling via
Mix_Playing() method, but I’m not sure of the whole ramifications of this;
there might be other parts of the mixer that suffer this race condition.
(Ideally, we want a separate flag that is set before the Mix_ChannelFinish
callback runs, which is all that Mix_Playing should check; I’ll add that
to my TODO list for when I rip into SDL_mixer later on.)
On a related note, the mixer effects API is almost complete; I’ll put that
patch on my website, so I don’t have to flood the list again. 
–ryan.
--- SDL_mixer-virgin/mixer.c Sat Jun 9 21:48:15 2001
+++ SDL_mixer/mixer.c Tue Jun 26 00:07:11 2001
@@ -743,12 +743,16 @@
int i;
for ( i=0; i<num_channels; ++i ) {
- if ( mix_channel[i].playing > 0 ) {
+ if ((mix_channel[i].playing > 0) ||
+ (mix_channel[i].looping > 0))
+ {
++status;
}
}
} else {
- if ( mix_channel[which].playing > 0 ) {
+ if ((mix_channel[which].playing > 0) ||
+ (mix_channel[which].looping > 0))
+ {
++status;
}
}