On Wednesday, June 26, 2002, at 10:59 PM, Eric Lyons wrote:
I'm trying to adapt madplay as a server, with simplified settings (always stereo, no resampling, etc). The simplest form of this server (though perhaps not the one to implement) *continuously* decodes a stream read from a named pipe. If the read of the pipe fails, it decodes silence. Another named pipe is used to check the size of the server's buffer and to cause it to be flushed (and maybe shutdown/stop the server).
This could be done by having the input callback always return data (either from the pipe or silence), never returning MAD_FLOW_STOP. But I'm wondering about ASYNC mode, and whether using it would somehow be better/similar. Having trouble figuring out how async mode works and its application.
Any comments on the best way to do this?
The existing high-level API might not really be appropriate for this kind of architecture. Rather than *decoding* silence, you may as well simply supply zero PCM samples when no data is available for decoding. This assumes more of a "pull" architecture, where you call something to supply PCM samples, rather than the "push" that happens when the high-level API calls your output routine. This sort of architecture is possible, and has been done with MAD in CoolPlayer, but it requires use of the low-level API.
FYI, the async mode in the high-level API simply runs the decoder thread in a separate process; the mad_decoder_run() routine returns immediately. mad_decoder_message() can be called from the parent process to send messages and receive replies from the decoder process. This might be used, for example, when the main thread needs to retain control to process GUI events.
Secondarily, my madplay (x86 Linux,mad-0.14.2b with and without MMAP support) seems to barf after resuming from pause/stop. Just get noise (interesting noise, but not musical noise) out the audio device. Anyone else seen this behavior?
I've not heard of this before. Which audio output module are you using?
-- Rob Leslie rob@mars.org