You are not logged in.
Pages: 1
Hi to all .
I have a little problem with MPD, it uses too much cpu.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4906 luca 20 0 26748 4100 1248 S 35.0 1.6 1:03.64 mpd
I tried to update to mpd-svn but it's the same.
my .mpdconf
################################################################
music_directory "~/Desktop/mdig"
playlist_directory "~/.mpd/playlists"
db_file "~/.mpd/mpd.db"
log_file "~/.mpd/mpd.log"
error_file "~/.mpd/mpd.error"
######################## OPTIONAL PATHS ########################
pid_file "~/.mpd/mpd.pid"
state_file "~/.mpd/mpdstate"
###############################################################
bind_to_address "127.0.0.1"
#bind_to_address "any"
port "6600"
################################################################
i use testing repository.
Offline
This seems to be an alsa bug, if you pause and resume the track it should go down for a while.
I migrated to PulseAudio, which fixed this issue for me.
Offline
This seems to be an alsa bug, if you pause and resume the track it should go down for a while.
I migrated to PulseAudio, which fixed this issue for me.
Thanks
I decommented the OSS output from .mpdconf and now the cpu usage is normal
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5422 luca 20 0 26540 3672 844 S 1.3 1.4 0:03.99 mpd
Last edited by Zap (2008-04-25 15:23:08)
Offline
for completeness: http://bugs.archlinux.org/task/10203
Offline
That's surely not a mpd bug. I caught mpg123 having high cpu usage a couple of times.
Offline
This seems to be an alsa bug, if you pause and resume the track it should go down for a while.
I migrated to PulseAudio, which fixed this issue for me.
Did you follow only the wiki regarding PulseAudio? I've had trouble before to set it up with only that. And it's really interesting to have PulseAudio enabled - no more "close firefox because of youtube to watch my videos"
Offline
It appears the problem is with ALSA and libao.
There is a temporary solution here:
http://mpd.wikia.com/wiki/Troubleshooting_Libao
Specifically, put this within the alsa driver output section:
driver_options "period_size=50000"
henno.
Offline
I also got this problem. The above fix makes the cpu usage smaller, but it still exists. Anyone got permanent fix?
Offline
It appears the problem is with ALSA and libao.
There is a temporary solution here:
http://mpd.wikia.com/wiki/Troubleshooting_Libao
Specifically, put this within the alsa driver output section:
driver_options "period_size=50000"
henno.
I think you mean
audio_output {
type "alsa"
period_time "50000"
}
This is suggested in their man page to reduce CPU usage, and it seemed to cut it about in half for me, from 25-30% to about 12%
A better fix is indeed in order, as I've not seen any reason to bother with Pulseaudio (unless it might help with Flash performance as above user said???)
Offline
I can also report >20% CPU when using MPD through ALSA. Applying "period_size=50000" in mpd.conf was completely ineffective. Switching to OSS returns:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3906 k2t0f12d 20 0 11556 3292 2700 S 1.0 0.3 0:02.84 mpd
Cheers!
Last edited by k2t0f12d (2008-11-04 19:28:11)
Offline
I can also report >20% CPU when using MPD through ALSA. Applying "period_size=50000" in mpd.conf was completely ineffective. Switching to OSS returns:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3906 k2t0f12d 20 0 11556 3292 2700 S 1.0 0.3 0:02.84 mpd
Cheers!
You should have updated mpd to latest version and read this page:
http://mpd.wikia.com/wiki/Tuning
Apart from that: Great choice with oss
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
Thank you for that link. It explains everything.
Offline
OK, I was having the same problem, so I switched to OSS as well, and it worked... However, the alsa OSS emulation doesn't want to share the audio device with other programs. (I think dmix doesn't work in OSS emulation mode). Would Jack audio server work? I've never used jack before.
It's a very deadly weapon to know what you're doing
--- William Murderface
Offline
Haven't found a way to solve this without leaving ALSA. Any ideas?
Damnshock
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
Old thread, but it only uses 2% cpu here.
dnyy in IRC & Urban Terror
Offline
Hi, guys, that's not a alsa bug. Look at here:
http://www.mpg123.de/faq.shtml
http://alsa.opensrc.org/index.php/Dmix
It's because dmix is trying to resample your music on fly, which is cpu intensive, if you use direct hardware output, it gives you even better sound quality for most mp3, but with much lower CPU usage.
Last edited by yingwuzhao (2009-03-14 03:11:15)
Offline
Im using 0.16~ from the git repo and I get extremely high cpu usage only when a client, such as mpc, connects to the server and streams the current track. The cpu usage is around 100% on a 1.2GHz processor, this should be sufficient. If I connect to the server with ncmpc and then I select play (not streaming, just playing on the server) it remains around 2-4%. Im using httpd output only, and get jittery output.
Offline
I'm experiencing this problem as well. Sorry to bumpski this up...
I was advised by an op in #mpd that this is not an mpd problem but a decoder problem when mpd is playing a 'broken' mp3. I'm not sure what a broken mp3 file is.
But, I can't switch to OSSv4 because it doesn't recognize my microphone jacks
I always just restart mpd and it goes down immediately. Any advice, updates?
Offline
this is how i do it and it works:
asound.conf:
pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
rate 44100
}
}
}
pcm.dmixout {
# Just pass this on to the system dmix
type plug
slave {
pcm "dmix"
}
}
pcm.mixin {
type dsnoop
ipc_key 5978293 # must be unique for all dmix plugins!!!!
ipc_key_add_uid yes
slave {
pcm "hw:0,0"
channels 2
period_size 1024
buffer_size 4096
rate 44100
periods 0
period_time 0
}
bindings {
0 0
0 1
}
}
the mixin part is for applications like skype, because some microphones (select mixin device for capture device)
my mpd conf looks like this:
audio_output {
type "alsa"
name "My ALSA Device"
format "44100:16:2" # optional
mixer_type "software" # optional
}
My CPU usage is down to 1-2% now. only downside is that playing back movies needs samplerate conversion now, but i dont care,, CPU usage with movies is a bit higher anyway
Last edited by Rasi (2011-02-28 09:52:01)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
Sorry to bump this, but I do think that people should check this out if they use MPD, especially if they feel they have higher CPU usage than they should.
I feel that
audio_output {
type "alsa"
( other options )
device "hw:0,0"
}
is a good solution, but would be interested to hear other opinions.
By the way, I didn't read any of the posts above me.
Offline
make alsa use 44100hz as default samplerate... and make mplayer resample to 44100...
This way mplayer needs more CPU, but movies do need more anyway, so who cares...
And of course i said the same thing just 2 replies above...
Last edited by Rasi (2011-10-20 21:43:17)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
this is how i do it and it works:
...
My CPU usage is down to 1-2% now. only downside is that playing back movies needs samplerate conversion now, but i dont care,, CPU usage with movies is a bit higher anyway
This worked for me! Thanks, really helps my laptop battery life.
Offline
Pages: 1