On Friday, November 8, 2002, at 03:07 PM, Eric Lyons wrote:
Hmm, sadly the problem would appear to be something in output buffering.
After decode() finishes, I wait for more input to be available, then run decode() again (reallocating all the madplay buffers). But the player still seems to hold on to the last 1152 samples or so or something.
stop_audio() works, but when it starts playing again, nothing comes out but mush. Maybe I need to reset something in the output structure for when it comes 'round again? I'd been trying to avoid stop_audio as it may result in clicks, but it appears that's the buffer that needs flushing...
I gather what's happening is you're letting the output underflow while you wait for more input. Depending which audio output module you're using, and the characteristics of the underlying sound driver, different things may happen, and it's not unusual for the driver to stop and buffer the small amount of remaining audio passed to it until you've supplied enough for the driver to start up again.
stop_audio() is probably not the right solution, because it is asynchronous in nature. (It will try to stop the audio device even before it's finished playing the last buffer you've passed it.)
Three possible solutions:
1. Drain and re-initialize the audio module explicitly with AUDIO_COMMAND_FINISH and AUDIO_COMMAND_INIT.
2. Feed zero samples to the audio module continuously until more input is available. This might require some careful timing, but would be less expensive than tearing down and re-initializing the audio module.
3. Add a new audio module command to explicitly drain any buffered audio and pause the audio device until more data is available. This will require implementing the command for all the existing audio modules (or at least the ones you care about.)