lkml.org 
[lkml]   [2003]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Ingo Molnar and Con Kolivas 2.6 scheduler patches
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.135 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site