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.027 / U:88.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site