Howdy - I'm running madplay on an iPaq3670/Familiar0.8 (ARM arch) with a CF ethernet card. I play Shoutcast MP3 streams by piping wget -o - <stream-url> | madplay - , and it works really well - realtime decoding, full sound, no fan, otherwise useless HW :). But every 10-30 minutes or so, I get a net/Inet hiccup that interrupts the stream connection. wget hangs, and no data gets to madplay. I want to set up another process to watch madplay, and kill it when it stops playing, then restart it - this always works manually. But madplay doesn't seem to reliably emit output status info. the --verbose flag sends an updated "seconds" counter, but, since it doesn't send any newlines, it can't be parsed by piping it to a "read" in a shell script. And redirecting it to a file doesn't reliably update the file's ctime, either. If I "madplay -o wave:- | tee >/dev/dsp |watchdog", the system performance grinds to a halt, unlistenable.
I just want any technique that keeps my wget | madplay pipeline restarted all the time, with a minimum of restarts, which make an audible "clunk". Short of recoding (and cross-compiling) libmad with extra status hooks, is there any way to keep this little engine churning?
Matthew Rubenstein email@mattruby.com wrote:
But every 10-30 minutes or so, I get a net/Inet hiccup that interrupts the stream connection. wget hangs, and no data gets to madplay.
Is it really wget causing the trouble ?? Sounds more like a problem with the ethernet driver... ?? What's the chipset ??
I just want any technique that keeps my wget | madplay pipeline restarted all the time, with a minimum of restarts, which make an audible "clunk". Short of recoding (and cross-compiling) libmad with extra status hooks, is there any way to keep this little engine churning?
If madplay is the only thing writing to /dev/dsp, you could detect hangups by polling `grep $AUDIO_DEVICE /proc/interrupts`
Andre --