Mind you, top is obviously having some problems with the CPU timing here. ButI do notice other CPU-intensive jobs slowing down noticeably until I pauseXMMS, 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'tthink it is entirely an artifact of some /proc/stat change. I'm using atrident card, and my hunch is that xmms is using either a blocking write orselect() to wait for the output buffer to become free, and the driver isreturning right away instead of blocking (or indicating writeability when itshouldn't).

I don't know when exactly this started, but it was probably some time in the2.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'tnotice the unusual CPU utilization at first. I believe the trident driver hasseen some big changes in the past few months, perhaps one of them has aproblem?

Other mp3 players (mpg123, freeamp) don't have this problem on the samekernel/hardware, and xmms doesn't have this problem with the same kernel on adifferent system (a laptop with an nm256 sound chip), so I suspect it'ssomething about the way xmms is doing its audio output triggering a tridentdriver bug.Is anyone else seeing this? If so, I'll go build some old kernels and try tosee when the problem appeared. If not, I'll find a different player..