From: Ed Sweetman <firstname.lastname@example.org>
To: Christian Axelsson <email@example.com>
Cc: Lukas Kolbe <firstname.lastname@example.org>, email@example.com
Subject: Re: 2.6.0-test1-mm2 music skips
Date: Sun, 20 Jul 2003 21:21:43 -0400 [thread overview]
Message-ID: <3F1B4027.firstname.lastname@example.org> (raw)
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
>>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
>>System is as follows:
>>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.
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.
next prev parent reply other threads:[~2003-07-21 1:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-20 20:34 2.6.0-test1-mm2 music skips Lukas Kolbe
2003-07-20 21:12 ` Ed Sweetman
2003-07-20 21:56 ` Lukas Kolbe
2003-07-20 23:35 ` Antonio Vargas
2003-07-20 23:47 ` Christian Axelsson
2003-07-21 1:21 ` Ed Sweetman [this message]
2003-07-21 14:21 ` Takashi Iwai
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).