Hi, Rob (and all).
I'm trying to figure out how to tell the decoding process to flush the input buffer after a MAD_FLOW_STOP is returned from decode_input_read (in madplay.c).
It stops playing fine, but when I decode() again, it picks up from where it left off in the buffer. I want to retain this behavior too, but also have the ability to kill the current buffer when it restarts.
Is this not possible with the high-level API? Perhaps I can add a MAD_FLOW_FLUSH?
Eric.
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
On Tuesday, November 5, 2002, at 10:39 AM, Eric Lyons wrote:
I'm trying to figure out how to tell the decoding process to flush the input buffer after a MAD_FLOW_STOP is returned from decode_input_read (in madplay.c).
It stops playing fine, but when I decode() again, it picks up from where it left off in the buffer. I want to retain this behavior too, but also have the ability to kill the current buffer when it restarts.
Is this not possible with the high-level API? Perhaps I can add a MAD_FLOW_FLUSH?
Before you start decoding again, if you want to decode something different, you should call mad_stream_buffer() to reset the stream location. You may also want to reset the internal decoding state by calling mad_frame_mute() and mad_synth_mute().
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...
Eric. --- Rob Leslie rob@mars.org wrote:
On Tuesday, November 5, 2002, at 10:39 AM, Eric Lyons wrote:
I'm trying to figure out how to tell the decoding process to flush
the
input buffer after a MAD_FLOW_STOP is returned from
decode_input_read
(in madplay.c).
It stops playing fine, but when I decode() again, it picks up from where it left off in the buffer. I want to retain this behavior
too,
but also have the ability to kill the current buffer when it
restarts.
Is this not possible with the high-level API? Perhaps I can add a MAD_FLOW_FLUSH?
Before you start decoding again, if you want to decode something different, you should call mad_stream_buffer() to reset the stream location. You may also want to reset the internal decoding state by calling mad_frame_mute() and mad_synth_mute().
-- Rob Leslie rob@mars.org
__________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
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.)
-
Eric Lyons -
Rob Leslie