0001991: xmms2d consuming too much CPU

(0003054)
puzzles (developer)
08-06-23 18:16

Is that actually too much? Do you have any (cpu-hungry) effect plugins enabled, like equalizer, normalizer, vocoder, etc.? XMMS2 is just reading PCM data from a buffer a lot of the time, the rest of the time it's fetching data and decoding it. This could be causing the spikes you see.

This part I don't understand, "when the playback is paused (toggle) and then resumed, the CPU consumption is a number between 2% and 35% which changes with each toggle (sometimes it's between 2-5%, other times between 20-30%)" Are you saying that sometimes xmms2d is consuming 30% cpu while paused? *That* would be a bug for sure. :)

(0003055)
juhovh (developer)
08-06-23 18:33

I understood that as the CPU consumption spikes when resumed. But where is that number "2x35%" taken from? I would just like to know how this was measured so that there would be some way to reproduce.

(0003056)
CFF (reporter)
08-06-23 19:13

I'm not the original reporter, but I see this also (also builds-from-source, on x86 and x86_64 dual-core systems, on Debian Testing). I can see the CPU usage in any random tool -- top, gkrellm's CPU monitor, whatever. They also report that the majority of the time accounted as `system', not `user'. I didn't explicitly enable any plugins, so whatever I've got are the defaults. Oh, and the output plugin is ALSA.

And just to clarify for puzzles, when you start playing, xmms2 seems to `pick' a random amount of CPU to use. When you pause, usage drops to 0. On resume a new amount of CPU is `chosen' and remains steady until the next pause, so it's not really a "spike".

I've seen this happen with Ogg Vorbis files and streamed MP3. Haven't tried any other sources.

(0003057)
puzzles (developer)
08-06-23 19:18

Oh wow, now *that* is strange...

(0003058)
juhovh (developer)
08-06-23 19:20

I have xmms2-devel.git built from source on x86_64 dual-core system, Ubuntu 8.04. I can't get xmms2 go over 3% no matter how many times I pause and restart it and tried with at least MP3 and AAC. No effect plugins are in use either... My output plugin is pulse audio, I will continue to see if I can reproduce in the future. Should probably do some experiments with ALSA if it's an output problem...

(0003059)
Eclipser (developer)
08-06-23 19:22

What soundcards/alsa drivers are you using who have the problem, could be related to that crap also.

(0003060)
CFF (reporter)
08-06-23 19:30

Both my systems use the snd_hda_intel driver. So, might be a driver bug then, though I can't reproduce with non-xmms2 players.

lspci reports the sound cards are:
00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

I can't reproduce the symmptoms with non-xmms2 audio players though (tried ogg123 and audacity).

(0003061)
mehturt (reporter)
08-06-23 22:53

CFF, thanks for the clarification of CPU sage, that's what I see as well.
2x35% means 2 threads each consuming 35% CPU, measured using htop.
I was playing mp3s using ALSA output, other mp3 players don't consume as much CPU (tried mplayer, decibel).
I have intel chipset/driver, I will attach lspci tomorrow (when at work).

(0003062)
mehturt (reporter)
08-06-24 07:48

I'm using snd_hda_intel driver, with lspci reporting:
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)

(0003063)
andersg (administrator)
08-06-24 19:02

http://wiki.xmms2.xmms.se/wiki/Why_does_XMMS2_use_so_much_CPU [^]

(0003087)
marten (reporter)
08-07-05 22:06

I have the same problem on my laptop. Seems that it is snd_hda_intel. I've uploaded profiling information from oprofile

(0003088)
marten (reporter)
08-07-05 22:21
edited on: 08-07-05 22:27

I changed output.buffersize from 32768 to 65536 and it helped. I'm not sure the problem went away completely, but now xmms2d load is about 2-7% (was 32-35%)

UPD: after xmms2 restart load increased to 20-25% again

(0003113)
bdrung (reporter)
08-07-22 11:42

I have the same problem. I am running xmms2 0.5 (from my PPA: https://launchpad.net/~bdrung/+archive [^] ) on Ubuntu 8.04 x86_64 using the ALSA output plugin. xmms2 uses 20% - 40% of one core (having a Core 2 Duo E6750). oprofile shows that snd_emu10k1 uses all the cpu power. Sometimes the usage goes up to 100 % of one core. When I pause the playback and resume, the usage goes back to 20% - 40% of one core.

lspci shows:
07:00.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value

$ cat /proc/asound/cards
0 [HDMI ]: HDA-Intel - HDA ATI HDMI
HDA ATI HDMI at 0xe0310000 irq 17
1 [Audigy2 ]: Audigy2 - Audigy 4 [SB0610]
Audigy 4 [SB0610] (rev.0, serial:0x10211102) at 0x1000, irq 21

The pulse output plugin does not have this problem, but pulse has a bug ( https://launchpad.net/bugs/221038 [^] ) that made it impossible to use pulse.

(0003123)
gimpel (reporter)
08-07-26 23:44
edited on: 08-07-26 23:54

I have to confirm this issue.

* AMD64 x86_64 dual core
* xmms2-devel.git
* ICE1712 ALSA drivers (rock solid)
* standard compiler options
* alsa 1.0.17 (drivers, libs, utils etc)
* alsa output plugin

average CPU usage when playing a 192 mp3 is around 40-50%

I would go and try to turn off unneded plugins like normalize and replaygain, but I have no idea on how to do that yet.

(0003124)
Eclipser (developer)
08-07-27 00:00

Try setting alsa device to hw:0,0 (or hw:0,1 or something), the 'default' might come with some dmix crap... or use oss :)

(0003125)
gimpel (reporter)
08-07-27 00:19
edited on: 08-07-27 00:22

It of course comes with dmix on default, even for the ICE1712 chip.
And for any non-pro-audio usage it is good that it is enabled. I use default device all the time, only jackd gets hw:0 exclusively.

So that is not the issue. Anyways, trying hw:0,0 directly.
.. that does not work at all.

The log says:
----
ERROR: ../src/plugins/alsa/alsa.c:266: Sample format (1) not available for playback.
----

and it does say that for (0) (1) (2) (4) (8) (12) (14) and (16)

Well, sample format of ICE1712 is S32_LE

So this alsa output plugin works _only_ with default.

Using OSS is not an option, not even OSS4 ;)

(0003126)
bdrung (reporter)
08-07-27 00:20

Changing the alsa device from 'default' to 'hw:1,0' helps. The CPU usage is now at 0%. Thanks to Eclipser.

Which fault is the "dmix crap"?

(0003127)
Eclipser (developer)
08-07-27 00:24

Alsa and some of its drivers just sucks too much really, not that our alsa plugin is any good either really... dmix causes high CPU usage on some combinations (and our alsa plugin?) apparently

(0003128)
tilman (administrator)
08-07-27 00:36

To check whether it's alsa's fault:

xmms2 stop
xmms2 config output_plugin null
xmms2 play

(0003129)
gimpel (reporter)
08-07-27 00:49
edited on: 08-07-27 00:52

Well, it isn't ALSA fault after all. Uses 30-45% CPU with null output.
Files tested are ogg and mp3.

But something is strange as it's not real cpu usage.
top says:
Cpu(s): 1.8%us, 0.5%sy, 0.0%ni, 97.5%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
...
14181 tom 20 0 259m 8832 6000 S 31 0.4 1:52.75 xmms2d

Also the cpu stays cool.

With alsa it's
Cpu(s): 4.8%us, 7.1%sy, 0.0%ni, 88.0%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14181 tom 20 0 260m 9808 6524 S 55 0.5 2:41.83 xmms2d

(0003130)
tilman (administrator)
08-07-27 00:52

What kernel version are you running?

If it's Linux 2.6._26_, then the CPU usage numbers top is giving you are probably totally wrong. At least that's what I'm seeing here (not just with xmms2...)

(0003131)
gimpel (reporter)
08-07-27 01:00

This indeed is 2.6.26-rc8-mm1.

Just spotted that an ffmpeg encoding process with 2 threads takes 189%. Interesting.

So this really is a kernel issue here! Sorry for the noise, and thanks tilman for the hint!

Still, alsa output needs to support S32_LE (it does support S32 it seems), but that's a different bug.

(0003133)
mehturt (reporter)
08-07-28 07:51

Confirming - setting device to hw:0 fixes the problem here as well.

(0003134)
nano (manager)
08-07-29 13:50

Can this bug be closed?

(0003135)
CFF (reporter)
08-07-29 16:00

Setting the device to hw:0 may or may not fix it here; I haven't tested it long enough to see as that also makes sound ignore the volume setting and always play at full volume, so it's not really a workable fix.

(0003136)
nano (manager)
08-07-29 16:01

pcm device != mixer device, separate configuration settings.

(0003137)
tilman (administrator)
08-07-29 17:28

If using the default device can commonly lead to excessive CPU usage, maybe the ALSA plugin should warn about this.

(0003159)
marten (reporter)
08-07-31 22:07

Problem dissapeared. Kernel 2.6.26-gentoo and alsa-driver 1.0.17

(0003160)
nano (manager)
08-08-01 12:06

Please update http://wiki.xmms2.xmms.se/wiki/Why_does_XMMS2_use_so_much_CPU [^] with your findings.

(0003417)
palbo (reporter)
09-01-06 21:01

The issue seems to be that dmix uses 48khz sample rate by default so if you're playing 44.1khz the dumb resampling uses more cpu.

Changing the dmix sample rate seems to solve it in my case.

Found here:
http://blog.sarine.nl/2008/12/21/dmix-the-pain-or-mpd-high-cpu-usage/ [^]

(0003616)
nano (manager)
09-02-16 22:44

The wiki was updated accordingly, I'm closing this bug.

Notes
(0003054) puzzles (developer) 08-06-23 18:16	Is that actually too much? Do you have any (cpu-hungry) effect plugins enabled, like equalizer, normalizer, vocoder, etc.? XMMS2 is just reading PCM data from a buffer a lot of the time, the rest of the time it's fetching data and decoding it. This could be causing the spikes you see. This part I don't understand, "when the playback is paused (toggle) and then resumed, the CPU consumption is a number between 2% and 35% which changes with each toggle (sometimes it's between 2-5%, other times between 20-30%)" Are you saying that sometimes xmms2d is consuming 30% cpu while paused? That would be a bug for sure. :)

(0003055) juhovh (developer) 08-06-23 18:33	I understood that as the CPU consumption spikes when resumed. But where is that number "2x35%" taken from? I would just like to know how this was measured so that there would be some way to reproduce.

(0003056) CFF (reporter) 08-06-23 19:13	I'm not the original reporter, but I see this also (also builds-from-source, on x86 and x86_64 dual-core systems, on Debian Testing). I can see the CPU usage in any random tool -- top, gkrellm's CPU monitor, whatever. They also report that the majority of the time accounted as `system', not `user'. I didn't explicitly enable any plugins, so whatever I've got are the defaults. Oh, and the output plugin is ALSA. And just to clarify for puzzles, when you start playing, xmms2 seems to `pick' a random amount of CPU to use. When you pause, usage drops to 0. On resume a new amount of CPU is `chosen' and remains steady until the next pause, so it's not really a "spike". I've seen this happen with Ogg Vorbis files and streamed MP3. Haven't tried any other sources.

(0003057) puzzles (developer) 08-06-23 19:18	Oh wow, now that is strange...

(0003058) juhovh (developer) 08-06-23 19:20	I have xmms2-devel.git built from source on x86_64 dual-core system, Ubuntu 8.04. I can't get xmms2 go over 3% no matter how many times I pause and restart it and tried with at least MP3 and AAC. No effect plugins are in use either... My output plugin is pulse audio, I will continue to see if I can reproduce in the future. Should probably do some experiments with ALSA if it's an output problem...

(0003059) Eclipser (developer) 08-06-23 19:22	What soundcards/alsa drivers are you using who have the problem, could be related to that crap also.

(0003060) CFF (reporter) 08-06-23 19:30	Both my systems use the snd_hda_intel driver. So, might be a driver bug then, though I can't reproduce with non-xmms2 players. lspci reports the sound cards are: 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) I can't reproduce the symmptoms with non-xmms2 audio players though (tried ogg123 and audacity).

(0003061) mehturt (reporter) 08-06-23 22:53	CFF, thanks for the clarification of CPU sage, that's what I see as well. 2x35% means 2 threads each consuming 35% CPU, measured using htop. I was playing mp3s using ALSA output, other mp3 players don't consume as much CPU (tried mplayer, decibel). I have intel chipset/driver, I will attach lspci tomorrow (when at work).

(0003062) mehturt (reporter) 08-06-24 07:48	I'm using snd_hda_intel driver, with lspci reporting: 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)

(0003063) andersg (administrator) 08-06-24 19:02	http://wiki.xmms2.xmms.se/wiki/Why_does_XMMS2_use_so_much_CPU [^]

(0003087) marten (reporter) 08-07-05 22:06	I have the same problem on my laptop. Seems that it is snd_hda_intel. I've uploaded profiling information from oprofile

(0003088) marten (reporter) 08-07-05 22:21 edited on: 08-07-05 22:27	I changed output.buffersize from 32768 to 65536 and it helped. I'm not sure the problem went away completely, but now xmms2d load is about 2-7% (was 32-35%) UPD: after xmms2 restart load increased to 20-25% again

(0003113) bdrung (reporter) 08-07-22 11:42	I have the same problem. I am running xmms2 0.5 (from my PPA: https://launchpad.net/~bdrung/+archive [^] ) on Ubuntu 8.04 x86_64 using the ALSA output plugin. xmms2 uses 20% - 40% of one core (having a Core 2 Duo E6750). oprofile shows that snd_emu10k1 uses all the cpu power. Sometimes the usage goes up to 100 % of one core. When I pause the playback and resume, the usage goes back to 20% - 40% of one core. lspci shows: 07:00.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value $ cat /proc/asound/cards 0 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xe0310000 irq 17 1 [Audigy2 ]: Audigy2 - Audigy 4 [SB0610] Audigy 4 [SB0610] (rev.0, serial:0x10211102) at 0x1000, irq 21 The pulse output plugin does not have this problem, but pulse has a bug ( https://launchpad.net/bugs/221038 [^] ) that made it impossible to use pulse.

(0003123) gimpel (reporter) 08-07-26 23:44 edited on: 08-07-26 23:54	I have to confirm this issue. * AMD64 x86_64 dual core * xmms2-devel.git * ICE1712 ALSA drivers (rock solid) * standard compiler options * alsa 1.0.17 (drivers, libs, utils etc) * alsa output plugin average CPU usage when playing a 192 mp3 is around 40-50% I would go and try to turn off unneded plugins like normalize and replaygain, but I have no idea on how to do that yet.

(0003124) Eclipser (developer) 08-07-27 00:00	Try setting alsa device to hw:0,0 (or hw:0,1 or something), the 'default' might come with some dmix crap... or use oss :)

(0003125) gimpel (reporter) 08-07-27 00:19 edited on: 08-07-27 00:22	It of course comes with dmix on default, even for the ICE1712 chip. And for any non-pro-audio usage it is good that it is enabled. I use default device all the time, only jackd gets hw:0 exclusively. So that is not the issue. Anyways, trying hw:0,0 directly. .. that does not work at all. The log says: ---- ERROR: ../src/plugins/alsa/alsa.c:266: Sample format (1) not available for playback. ---- and it does say that for (0) (1) (2) (4) (8) (12) (14) and (16) Well, sample format of ICE1712 is S32_LE So this alsa output plugin works _only_ with default. Using OSS is not an option, not even OSS4 ;)

(0003126) bdrung (reporter) 08-07-27 00:20	Changing the alsa device from 'default' to 'hw:1,0' helps. The CPU usage is now at 0%. Thanks to Eclipser. Which fault is the "dmix crap"?

(0003127) Eclipser (developer) 08-07-27 00:24	Alsa and some of its drivers just sucks too much really, not that our alsa plugin is any good either really... dmix causes high CPU usage on some combinations (and our alsa plugin?) apparently

(0003128) tilman (administrator) 08-07-27 00:36	To check whether it's alsa's fault: xmms2 stop xmms2 config output_plugin null xmms2 play

(0003129) gimpel (reporter) 08-07-27 00:49 edited on: 08-07-27 00:52	Well, it isn't ALSA fault after all. Uses 30-45% CPU with null output. Files tested are ogg and mp3. But something is strange as it's not real cpu usage. top says: Cpu(s): 1.8%us, 0.5%sy, 0.0%ni, 97.5%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st ... 14181 tom 20 0 259m 8832 6000 S 31 0.4 1:52.75 xmms2d Also the cpu stays cool. With alsa it's Cpu(s): 4.8%us, 7.1%sy, 0.0%ni, 88.0%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st ... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14181 tom 20 0 260m 9808 6524 S 55 0.5 2:41.83 xmms2d

(0003130) tilman (administrator) 08-07-27 00:52	What kernel version are you running? If it's Linux 2.6._26_, then the CPU usage numbers top is giving you are probably totally wrong. At least that's what I'm seeing here (not just with xmms2...)

(0003131) gimpel (reporter) 08-07-27 01:00	This indeed is 2.6.26-rc8-mm1. Just spotted that an ffmpeg encoding process with 2 threads takes 189%. Interesting. So this really is a kernel issue here! Sorry for the noise, and thanks tilman for the hint! Still, alsa output needs to support S32_LE (it does support S32 it seems), but that's a different bug.

(0003133) mehturt (reporter) 08-07-28 07:51	Confirming - setting device to hw:0 fixes the problem here as well.

(0003134) nano (manager) 08-07-29 13:50	Can this bug be closed?

(0003135) CFF (reporter) 08-07-29 16:00	Setting the device to hw:0 may or may not fix it here; I haven't tested it long enough to see as that also makes sound ignore the volume setting and always play at full volume, so it's not really a workable fix.

(0003136) nano (manager) 08-07-29 16:01	pcm device != mixer device, separate configuration settings.

(0003137) tilman (administrator) 08-07-29 17:28	If using the default device can commonly lead to excessive CPU usage, maybe the ALSA plugin should warn about this.

(0003159) marten (reporter) 08-07-31 22:07	Problem dissapeared. Kernel 2.6.26-gentoo and alsa-driver 1.0.17

(0003160) nano (manager) 08-08-01 12:06	Please update http://wiki.xmms2.xmms.se/wiki/Why_does_XMMS2_use_so_much_CPU [^] with your findings.

(0003417) palbo (reporter) 09-01-06 21:01	The issue seems to be that dmix uses 48khz sample rate by default so if you're playing 44.1khz the dumb resampling uses more cpu. Changing the dmix sample rate seems to solve it in my case. Found here: http://blog.sarine.nl/2008/12/21/dmix-the-pain-or-mpd-high-cpu-usage/ [^]

(0003616) nano (manager) 09-02-16 22:44	The wiki was updated accordingly, I'm closing this bug.

Issue History
Date Modified	Username	Field	Change
08-06-23 12:55	mehturt	New Issue
08-06-23 18:16	puzzles	Note Added: 0003054
08-06-23 18:33	juhovh	Note Added: 0003055
08-06-23 19:13	CFF	Note Added: 0003056
08-06-23 19:18	puzzles	Note Added: 0003057
08-06-23 19:20	juhovh	Note Added: 0003058
08-06-23 19:22	Eclipser	Note Added: 0003059
08-06-23 19:30	CFF	Note Added: 0003060
08-06-23 22:53	mehturt	Note Added: 0003061
08-06-24 07:48	mehturt	Note Added: 0003062
08-06-24 19:02	andersg	Note Added: 0003063
08-07-05 16:38	marten	Issue Monitored: marten
08-07-05 22:05	marten	File Added: prof
08-07-05 22:06	marten	Note Added: 0003087
08-07-05 22:21	marten	Note Added: 0003088
08-07-05 22:21	marten	Note Edited: 0003088
08-07-05 22:27	marten	Note Edited: 0003088
08-07-22 11:42	bdrung	Note Added: 0003113
08-07-22 11:58	bdrung	Issue Monitored: bdrung
08-07-26 23:44	gimpel	Note Added: 0003123
08-07-26 23:45	gimpel	Note Edited: 0003123
08-07-26 23:51	gimpel	Note Edited: 0003123
08-07-26 23:54	gimpel	Note Edited: 0003123
08-07-27 00:00	Eclipser	Note Added: 0003124
08-07-27 00:19	gimpel	Note Added: 0003125
08-07-27 00:20	bdrung	Note Added: 0003126
08-07-27 00:22	gimpel	Note Edited: 0003125
08-07-27 00:24	Eclipser	Note Added: 0003127
08-07-27 00:24	gimpel	Issue Monitored: gimpel
08-07-27 00:36	tilman	Note Added: 0003128
08-07-27 00:49	gimpel	Note Added: 0003129
08-07-27 00:50	gimpel	Note Edited: 0003129
08-07-27 00:52	gimpel	Note Edited: 0003129
08-07-27 00:52	tilman	Note Added: 0003130
08-07-27 01:00	gimpel	Note Added: 0003131
08-07-28 07:51	mehturt	Note Added: 0003133
08-07-29 13:50	nano	Note Added: 0003134
08-07-29 13:50	nano	Status	new => feedback
08-07-29 16:00	CFF	Note Added: 0003135
08-07-29 16:01	nano	Note Added: 0003136
08-07-29 17:28	tilman	Note Added: 0003137
08-07-31 22:07	marten	Note Added: 0003159
08-08-01 12:06	nano	Note Added: 0003160
09-01-06 21:01	palbo	Note Added: 0003417
09-02-16 22:44	nano	Note Added: 0003616
09-02-16 22:44	nano	Status	feedback => closed
09-02-16 22:44	nano	Resolution	open => no change required
09-02-16 22:44	nano	Fixed in Version	=> 0.6 DrM
09-02-16 22:44	nano	Target Version	=> 0.6 DrM

Relationships [ Relation Graph ] [ Dependency Graph ]