Re: 2.6.0-test1-mm2 music skips

From: Ed Sweetman (
Date: Sun Jul 20 2003 - 20:21:43 EST

Christian Axelsson wrote:
> On Sun, 2003-07-20 at 22:34, Lukas Kolbe wrote:
>>Just wanted to let you know that on my System (Debian Sid, Kernel
>>2.6.0-test1-mm2, .config attached) I get sound-skips with all recent
>>Kernels (tested 2.5.69 'til 2.6.0-test1-mm2).
>>With each new version it gets better, but I still can produce
>>For music-hearing-pleasure I use xmms, it plays .oggs, .mp3s.
>>With .mp3s I potentially get more skips than with .oggs.
>>The skips occur while switching desktops in Gnome 2.2 with many windows
>>open, or while marking the Desktop drawn by Nautilus with it's
>>nice-looking shading square, or while starting large apps like the Gimp
>>or Mozilla.
>>Intersting though is that I'm not able to produce audio-skips for Mod's
>>(.mt2, .xm, .it) in xmms.
>>A switch from X to a VC and back also reproducibly produces a ~1.5
>>seconds skip.
>>System is as follows:
>>Duron 1.3
>>Elitegroup K7S5A
>>WDC WD800BB-00CAA0
>>Ensoniq 5880 AudioPCI (rev 02)
>>nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1)
>>And no, Xfree is not reniced :)
>>I'm not on the list, so pleas Cc me on reply. Although I'm periodically
>>reading the archives.
>>Can I help somehow?
> Please read the O*int threads.
> It's probably Con's new scheduler that is causing these problems.
> If you are using alsa, try the OSS emulation as it seems to help abit.

I've been using the 2.5 kernel for a long time now and the 2.4 kernel
since it was just turned into 2.3. There have been these "problems"
since 2.3, this is not something new caused by any new schedulers. The
schedulers can cause problems, no doubt, but they also make userspace
programming issues apparent. The fact that going to oss emu only proves
that this is mostly a userspace problem. ALSA drivers have to be coded
with much more attention to latency because it's very specific about
being run on time. You can only send it a small amount of data every
write you make to the soundcard. It's a tradeoff for low latency. Some
of the plugins in these programs are just going to need to be
streamlined. The scheduler problems are problems when something is not
getting it's time on the cpu when it's niced to -20 by programs not
niced at that level. This is a scheduler problem. But i'm still rather
confident that the majority of skipping in audio playing is a userspace
problem brought on by being too lenient with how the decoder is looping
and deciding to loop. Players have to balance how much cpu they want
to be reported as using to how skip resistant they want to be. If you
only loop around once a second and you expect 3/4 of a second or a
second to be played by then, then you're likely to get skips when
something steal the cpu or is really using it. Players do this to use
less cpu because people assume less cpu usage automatically means it's
better. You could also simply tune that plugin to loop every 1/4 second
  and it would be exponentially harder to cause a skip but it would use
more cpu. And that's not counting less than efficient decoding loops.
etc etc.

I'd suggest testing against players using different decoders (different
players as well) and seeing if the problem is exactly the same for all
of them. I seriously doubt it will be found that it is.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:41 EST