From: Daniel Phillips <phillips@arcor.de>
To: Ed Sweetman <ed.sweetman@wmich.edu>
Cc: Andrew Morton <akpm@osdl.org>,
eugene.teo@eugeneteo.net, linux-kernel@vger.kernel.org,
kernel@kolivas.org
Subject: Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches
Date: Fri, 1 Aug 2003 10:38:49 -0500 [thread overview]
Message-ID: <200308011038.49528.phillips@arcor.de> (raw)
In-Reply-To: <3F22FB33.5080703@wmich.edu>
On Saturday 26 July 2003 17:05, Ed Sweetman wrote:
> My comment was towards the fact that although playing audio is a
> realtime priority, decoding audio is not, and is not coded that way in
> many programs, in fact, many programs will sleep() in order to decode
> only when the output buffer is getting low.
Decoding is realtime too, though the bounds are more relaxed than for the DMA
refill process. In fact, it's the decoding task that causes skipping,
because the DMA refill normally runs in interrupt context (so should mixing
and equalizing, but that's another story) where essentially everything is
realtime, modulo handwaving.
To convince yourself of this, note that when DMA refill fails to meet its
deadline you will hear repeats, not skipping, because the DMA hardware on the
sound card has been set up to automatically restart the DMA each time the
buffer expires. Try running the kernel under kgdb and breaking to the
monitor while sound is playing.
So you need to reevaluate your thinking re the realtime nature of audio
decoders.
To be sure, for perfect audio reproduction, any file IO involved has to be
realtime as well, as does the block layer. We're not really in position to
take care of all that detail at this point, mainly because no Linux
filesystem has realtime IO support. (I believe Irix XFS has realtime IO and
that part didn't get ported because of missing infrastructure in Linux.) But
the block layer isn't really that far away from being able to make realtime
guarantees. Mainly, that work translates into plugging in a different IO
scheduler.
Beyond that, there's priority inversion to worry about, which is a hard
problem from a theoretical point of view. However, once we get to the point
where priority inversion is the worst thing about Linux audio, we will be
lightyears ahead of where we now stand.
> Technically, you shouldn't be
> able to get aplay to skip at all as long as no other processes are at an
> equal or higher nice value.
This got fuzzier with the interactivity hacks, which effectively allow the
nice values to vary within some informally defined range.
Regards,
Daniel
next prev parent reply other threads:[~2003-07-31 15:38 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-26 9:30 Ingo Molnar and Con Kolivas 2.6 scheduler patches Felipe Alfaro Solana
2003-07-26 9:46 ` Marc-Christian Petersen
2003-07-26 10:02 ` Ismael Valladolid Torres
2003-07-26 10:10 ` Eugene Teo
2003-07-26 11:24 ` Ed Sweetman
2003-07-26 17:00 ` Rahul Karnik
2003-07-27 15:46 ` Daniel Phillips
2003-07-26 16:52 ` Diego Calleja García
2003-07-26 18:35 ` Andrew Morton
2003-07-26 23:01 ` Diego Calleja García
2003-07-28 9:38 ` Felipe Alfaro Solana
2003-07-28 10:37 ` Måns Rullgård
2003-07-28 17:06 ` Diego Calleja García
2003-07-27 2:38 ` Con Kolivas
2003-07-27 7:39 ` Willy Tarreau
2003-07-27 9:12 ` Ingo Molnar
2003-07-27 11:54 ` Con Kolivas
2003-07-27 20:18 ` Daniel Phillips
2003-07-26 22:05 ` Ed Sweetman
2003-08-01 15:38 ` Daniel Phillips [this message]
2003-07-31 23:02 ` Ed Sweetman
2003-07-27 2:39 ` Ed Sweetman
2003-07-29 13:56 ` Timothy Miller
2003-07-29 13:57 ` Con Kolivas
2003-07-29 15:30 ` Timothy Miller
2003-07-29 15:52 ` Helge Hafting
2003-07-29 16:26 ` Timothy Miller
2003-07-30 14:46 ` Daniel Phillips
2003-07-29 15:40 ` Timothy Miller
2003-07-30 16:17 ` Daniel Phillips
2003-08-08 21:09 ` Bill Huey
2003-08-06 21:28 ` Rob Landley
2003-08-07 9:34 ` Helge Hafting
2003-08-07 15:42 ` Daniel Phillips
2003-08-07 20:45 ` William Lee Irwin III
2003-08-07 20:51 ` Rob Landley
2003-08-07 21:40 ` Ed Sweetman
2003-08-07 22:17 ` William Lee Irwin III
2003-08-08 0:01 ` Rob Landley
2003-08-09 20:52 ` George Anzinger
2003-08-14 0:24 ` Rob Landley
2003-08-14 8:01 ` George Anzinger
2003-08-16 9:10 ` Rob Landley
2003-08-16 14:29 ` APM and 2.5.75 not resuming properly Jamie Lokier
2003-08-16 15:03 ` Stephen Rothwell
2003-08-16 16:12 ` Jamie Lokier
2003-08-16 20:43 ` Rob Landley
2003-08-13 3:38 ` Ingo Molnar and Con Kolivas 2.6 scheduler patches George Anzinger
2003-08-08 6:08 ` Daniel Phillips
2003-07-26 12:08 ` Ismael Valladolid Torres
2003-07-26 14:54 ` Con Kolivas
2003-07-26 14:49 ` Con Kolivas
2003-07-26 14:47 ` Con Kolivas
2003-07-26 16:42 ` Lou Langholtz
2003-07-26 16:40 ` Jens Axboe
2003-07-26 18:19 ` William Lee Irwin III
2003-07-26 18:31 ` Felipe Alfaro Solana
2003-07-26 19:20 ` William Lee Irwin III
2003-07-26 19:47 ` William Lee Irwin III
2003-07-27 9:24 ` Ingo Molnar
2003-07-27 9:57 ` Con Kolivas
2003-07-27 10:02 ` Ingo Molnar
2003-07-27 10:19 ` Con Kolivas
2003-07-28 22:44 ` Timothy Miller
2003-07-26 14:44 Downing, Thomas
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200308011038.49528.phillips@arcor.de \
--to=phillips@arcor.de \
--cc=akpm@osdl.org \
--cc=ed.sweetman@wmich.edu \
--cc=eugene.teo@eugeneteo.net \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).