lkml.org 
[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjecttrident.c vs. XMMS: 100% CPU usage

I was wondering if anyone else is seeing what I'm seeing: while I'm playing
songs with "xmms", my CPU utilization gets pegged at 100% system, and "top"
reports that xmms is using almost all of it:


12:50am up 5 days, 47 min, 5 users, load average: 0.72, 0.45, 0.25
78 processes: 75 sleeping, 2 running, 1 zombie, 0 stopped
CPU states: 1.9% user, 198.0% system, 0.0% nice, 848707.7% idle
Mem: 126952K av, 120360K used, 6592K free, 0K shrd, 2452K buff
Swap: 130748K av, 25760K used, 104988K free 52336K cached

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
14464 warner 11 0 4296 3564 1280 R 0 99.9 2.8 7:07 xmms
14757 warner 6 0 1356 1356 688 R 0 2.3 1.0 0:00 top
29254 root 0 0 32384 11M 1032 S 0 0.7 9.3 52:43 XF86_SVGA
14463 warner 0 0 4296 3564 1280 S 0 0.3 2.8 0:01 xmms
1 root 0 0 108 64 48 S 0 0.0 0.0 0:08 init
2 root 0 0 0 0 0 SW 0 0.0 0.0 8:18 kswapd
3 root 0 0 0 0 0 SW 0 0.0 0.0 0:20 kflushd
4 root 0 0 0 0 0 SW 0 0.0 0.0 0:04 kupdate
124 root 0 0 324 288 216 S 0 0.0 0.2 0:20 syslogd


Mind you, top is obviously having some problems with the CPU timing here. But
I do notice other CPU-intensive jobs slowing down noticeably until I pause
XMMS, and heavy video activity (moving windows around, scrolling Netscape)
has more of a detrimental effect on audio playback than it used to, so I don't
think it is entirely an artifact of some /proc/stat change. I'm using a
trident card, and my hunch is that xmms is using either a blocking write or
select() to wait for the output buffer to become free, and the driver is
returning right away instead of blocking (or indicating writeability when it
shouldn't).

I don't know when exactly this started, but it was probably some time in the
2.3.40s . I'm at 2.3.99-pre2 now, and didn't see any trident.c changes in
-pre3. I usually play my mp3s while doing lots of other stuff, so I didn't
notice the unusual CPU utilization at first. I believe the trident driver has
seen some big changes in the past few months, perhaps one of them has a
problem?

Other mp3 players (mpg123, freeamp) don't have this problem on the same
kernel/hardware, and xmms doesn't have this problem with the same kernel on a
different system (a laptop with an nm256 sound chip), so I suspect it's
something about the way xmms is doing its audio output triggering a trident
driver bug.

Is anyone else seeing this? If so, I'll go build some old kernels and try to
see when the problem appeared. If not, I'll find a different player..

kernel 2.3.99-pre2
xmms version 1.0.1, using the "OSS output driver v1.0.1"
kernel: Trident 4DWave/SiS 7018 PCI Audio, version 0.14, 22:59:12 Mar 19 2000
kernel: trident: Trident 4DWave DX found at IO 0xd000, IRQ 10
kernel: ac97_codec: AC97 Audio codec, vendor id1: 0x8384, id2: 0x7605 (SigmaTel STAC9704)


cheers,
-Brian
warner@lothar.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.919 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site