Very high cpu usage in raspberrypi

Submitted by shdgrao on Wed, 2012-12-05 17:18

Forums:

Hi. I have just installed moc via apt-get in a clean Raspbian distribution (latest version). It works well but its consuming all the cpu available. I have tried playing mp3 and flac. I happens all the same. If I play music with other player (like omxplayer), the cpu usage is normal (around 20%). Don't these two player should use the same decoding libraries and have similar cpu usage?

Thank you.

Pablo

jcf

Wed, 2012-12-05 17:35

It sounds reasonable to me that MOC should exhibit similar resource usage as other players. I know someone with a Raspberry Pi so I'll see if he can confirm this behaviour, but any additional clues are welcome.

shdgrao

Fri, 2012-12-07 12:05

I have just compiled moc stable (2.4.4) with mp3 support and the same, 100% of cpu usage. I tried with other console players like cmus and the cpu usage is normal. I just don't understand what is happening.

Pablo

jcf

Mon, 2013-01-21 01:54

After investigations by Antonio ("sagitter") and myself (and independantly by "tomaszg" and "1984") I have come to the conclusion that this is not a MOC bug. We have proven it is a bug in ALSA, probably the one fixed in alsa-lib commit 3fd4ab9b, and is sensitive to sampling rate and sample width.

The solution is to upgrade to a later version of alsa-lib. (Version 1.0.26 on Fedora does not exhibit this bug on the RPi although the above patch was committed after the release of 1.0.26.) A possible circumvention is to run MOC with the configuration option ALSADevice="hw:0,0"; the "hw:0,0" device is not usable on all systems (and a MOC assertion or ALSA error may result), but when usable it does work and the CPU load drops from near 100% to around 7% in our tests.

sagitter

Wed, 2013-01-23 14:19

Version 1.0.26 on Fedora does not exhibit this bug on the RPi although the above patch was committed after the release of 1.0.26.

The RPM for Fedora ARM is here; tested on Fedora 17 ARM (stable).

jcf

Mon, 2013-03-25 22:00

Nothing further heard -- problem closed.

tomaszg

Sun, 2012-12-09 00:01

What decoder do you use for mp3 and flac files? I've been successfully running MOC on OpenWRT TP-Link box, so it should easily work on RPi. Try disabling ffmpeg (or contrary - enabling it ;) ).

If you would want to play Ogg Vorbis, you can try enabling the fixed-point Tremor decoding library added in 2.5.0-beta1.

1984

Sun, 2013-01-13 13:31

I've got the same issue with my raspberry. I've also tried it with .ogg and .wma files and the problem also exists. I've tried using no ffmpeg and it didn't change anything.

Here's the discussion of the raspberry forum (that the threadstarter here also started): http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=24647&p=257780

There it seems that it's related to the sound chip of the raspberry. Is there any way to find out which part of moc exactly needs that much of the cpu?

tomaszg

Sun, 2013-01-13 14:08

You wrote on rpi forum:
"I wrote some piece of software to control moc only by mouse (i don't have a keyboard or display connected)."

Could you elaborate? I'm still looking for ideas to control my openwrt moc.

Concerning the bug itself: if it is really driver issue, maybe a patch I was writing a patch would help (or at least provide more data) - it allows to disable some sound formats in ALSA (as an extension of Allow24BitOutput option now present). If you wish to check it, I'll send you an email.

You could also try to use OSS in MOC (if raspbian provides OSS emulation). And check reported print_output_capabilities() in mocp_server_log.

1984

Mon, 2013-01-14 09:19

Hi,

please write me an e-mail with the patch, how to properly apply it, and what information I should search for. I had some problems compiling moc for my raspberry but I'll figure that out.

Here's what I got for print_output_capabilities() in the server log:

ALSA:
audio.c:956 print_output_capabilities(): Sound driver capabilities: channels 1 - 10000, formats: 8-bit signed, 8-bit unsigned, 16-bit signed, 16-bit unsigned, 24-bit signed (as 32-bit samples), 24-bit unsigned (as 32-bit samples) little-endian (native)

OSS:
Unfortunately it didn't work for OSS. As soon as I start a song with moc using OSS my ssh connection doesn't react anymore.

Offtopic: I didn't do anything special to control moc by mouse. As mentioned I don't have a screen and keyboard attached to my raspberry. I wanted a little radio that I can control by mouse. So I wrote a little daemon that listens to the /dev/input/event0 file (which is the input stream from this mouse) and interprets each key of the mouse as a command to moc and executes it by the system() command of C. It's less than 100 LOC in C but I have a little radio run on moc controlled by mouse :)
I can give you the code but it's really nothing special (except for me).

EDIT:
I thought I would have to start a file to get the desired line in the server log for OSS. So now I looked again and here it is:

Jan 14 10:11:34.135244: audio.c:948 print_output_capabilities(): Sound driver capabilities: channels 1 - 2, formats: 8-bit signed, 8-bit unsigned, 16-bit signed little-endian (native)

jcf

Sun, 2013-01-13 22:50

I also saw this (and associated) threads when I first investigated the problem and believe it is probably the explanation. But those threads don't seem to have progressed since I first looked at them.

I am still waiting for the "someone" to find some spare time (Summer holidays and all that), but maybe someone who knows a bit more about the RaspberryPi could lend a hand to either confirm or eliminate the sound chip or its driver as the cause of this problem.

1984

Sun, 2013-01-13 21:33

I compiled 2.5.0-beta1 on the raspberry and the problem still exists. Here's how I compiled:

$ mocp -V

This is : Music On Console
Version : 2.5.0-beta1
Revision : 2506
Built : Jan 13 2013 22:18:35
Compiled with : OSS ALSA JACK DEBUG Network streams resample
Running on : Linux 3.2.27+ armv6l

1984

Sat, 2013-01-19 14:25

There's a workaround (that at least works for me) for the raspberry package:

Set the option 'Allow24bitOutput' in your '.moc/config' to 'yes'. Normally it should be set to 'no'.

Thanks to tomaszg for suggesting this :)

tomaszg

Sat, 2013-01-19 14:36

In my opinion, this option should be set to "yes" generally and only disabled in specific cases of broken soundcard drivers :)

1984

Sat, 2013-01-19 14:45

I just wanted to say that in the std config file it is set to 'no'. ;)

tomaszg

Sat, 2013-01-19 14:51

I understand, but I wanted just for the record remark, that it is safe and reasonable to turn it on always, unless you have a reason not to. :)