Raspberry Pi Streaming Radio Player: Improved Pipe Handling

My Raspberry Pi-based streaming radio player generally worked fine, except sometimes the keypad / volume control knob would stop responding after switching streams. This being an erratic thing, the error had to be a timing problem in otherwise correct code and, after spending Quality Time with the Python subprocess and select doc, I decided I was abusing mplayer’s stdin and stdout pipes.

This iteration registers mplayer’s stdout pipe as Yet Another select.poll() Polling Object, so that the main loop can respond whenever a complete line arrives. Starting mplayer in quiet mode reduces the tonnage of stdout text, at the cost of losing the streaming status that I really couldn’t do anything with, and eliminates the occasional stalls when mplayer (apparently) dies in the middle of a line.

The code kills and restarts mplayer whenever it detects an EOF or stream cutoff. That works most of the time, but a persistent server or network failure can still send the code into a sulk. Manually selecting a different stream (after we eventually notice the silence) generally sets things right, mainly by whacking mplayer upside the head; it’s good enough.

It seems I inadvertently invented streaming ad suppression by muting (most of) the tracks that produced weird audio effects. Given that the “radio stations” still get paid for sending ads to me, I’m not actually cheating anybody out of their revenue: I’ve just automated our trips to the volume control knob. The audio goes silent for a few seconds (or, sheesh, a few minutes) , blatting a second or two of ad noise around the gap to remind us of what we’re missing; given the prevalence of National Forest Service PSAs, the audio ad market must be a horrific wasteland.

The Python source code as a GitHub Gist:

One thought on “Raspberry Pi Streaming Radio Player: Improved Pipe Handling

  1. It seems I inadvertently invented streaming ad suppression

    Wow, you invented Carl Sagans Adnix :)

    Back in the day when I had a TV (fortunately not anymore) I would be all over it :)
    Though Youtube ads are getting more annoying as time goes so who knows… :)

    For TV and radio I always thought that volume analysis would suffice. For their greedy reasons ads always run louder then the rest of program.
    Digital ads could be treated as viruses and identified by signatures, maybe even have a public database like we do for junk email :)

    It would raise the bar for commercial production at least, maybe to the point you’d want to see them once or twice :)

Comments are closed.