Messages in this thread | | | Date | 26 Mar 2000 09:06:48 -0000 | From | Brian Warner <> | Subject | trident.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/
| |