[mad-user] madplay watchdog signals?

[Matthew Rubenstein]

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?

[Andre]

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
--