pianobar on BBB causes occasional slowdown

Running “pianobar” on BBB with Debian Jessie. Works just fine most of the time.

Occasionally a hiccup will cascade into stuttering fit. The stream seems to continue to play, but very slowly. Not in an analog way but with widely separated bursts of sound. Pressing “p” for “pause” relieves the logjam and the stream resumes normal speed.

When such a fit occurs, the blue LED “heartbeat” slows visibly and speeds back up when the fit ends. Also, CPU usage of active processes, as reported in the top utility, roughly double during such a fit. There are no messages written to syslog either. It’s as if the CPU itself had slowed down.

I know there are a lot of components working together here, and my description is pretty vague. I’m just wondering if anyone has any ideas or similar experiences.

I myself wonder if buffering is somehow involved and think to experiment with mplayer since there is some buffering control available to users.

Thanks for reading.

Mark

Try forcing the performance governor, by default the ondemand is used.

Thank you for responding.

Changing the governor to “performance” has not worked.

But it has had an interesting effect: whereas the stuttering effect previously occurred occasionally, it now occurs immediately, as soon as the music starts, every time I start the program.

Also, the effect on the blue LED’s is different than I described at first. All the happens is that the LED that quickly flashes on and off freezes on while the LED with the “heart beat” pattern continues on unchanged.

And cpufreq-info continues to report max frequency even when the countdown clock in the pianobar display slows to a crawl.

Curious, huh?

Mark

What does top report?

How much free memory do you have?

Have you created a swap file?

Strange behaviors like this can happen when you start to run out of
memory and malloc() returns NULL (most programs don't really properly
handle this) or the kernel's OOM killer starts randomly killing processes.

What does top report?

When pianobar is running as it should: (I’m inserting a screen shot—I hope it works).

and when pianobar falls into a stutter top looks like this. The big change seems to be with CPU usage rather than memory:

How much free memory do you have?

Doesn’t seem to be a problem, but see the top screen shots

Have you created a swap file?

Doesn’t seem to have been activated.

Strange behaviors like this can happen when you start to run out of
memory and malloc() returns NULL (most programs don’t really properly
handle this) or the kernel’s OOM killer starts randomly killing processes.

Thanks for thinking about this.

An additional note on this.

Roughly the same thing happens to mplayer2 (using libav instead of the ffmpeg) but less frequently. A difference is that the cycle of the “stutter” is longer, but the effect of slowing the “heartbeat” LED and the doubling of the players’ CPU usage are the same. So I’ve got similar (mis)behavior with both pianobar/ffmpeg and mplayer2/libav. But I don’t at this point know how to go about getting a better diagnosis. No biggie; maybe it will tie into something else.

Mark