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