lkml.org 
[lkml]   [1999]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: real-time threaded IO with low latency (audio)
Paul Barton-Davis wrote:
(...)
> What they require is guaranteed maximum *jitter*. This is where the
> problem comes in. I don't believe that RTLinux is the required answer
> here.

No, not really. Quite a bit more than some 20 us jitter would be
acceptable...

> These applications are not hard real time in the sense that
> RTLinux has been written to support.

...but HARD real time is still an absolute requirement.

> All they ask is that the
> operating system never deny them resources if they want to use them
> and such use doesn't interfere with or require the cooperation of any
> other subsystem and/or process. That means "CPU hungry", not
> "absolutely constrained by timing issues".

I'd say both. In order to be usable for professional audio (live in
particular), these applications NEED to meet EVERY deadline. If there
can be occational drop-outs when doing reasonably low latency
processing, I'm going elsewhere.

Until now, dedicated DSP hardware has been the way of doing what
Audiality will do. Without hard real time, that won't change. The whole
idea with this hard real time engine is to enable low latency processing
without external hardware. It's NOT the average audio API, or
whatever... That part still belongs in soft real time user space.

> Linux doesn't do this right now. If someone else is using a "key"
> piece of the kernel, then nobody else may proceed in spite of the fact
> that proceeding would not utilize or corrupt any of the resources used
> by the current lock holder. That is, lock granularity is not only too
> large, but crosses distinct protection domains which should be
> independent.

Yep, I know, and fixing that might be enough. However, is that enough to
guarantee that a real time task will get control within any defined
time? I want figures. Hard, real, reliable figures.

> The "simple" change of explicitly recognizing the existence of
> distinct I/O subsystems would provide almost everything that a "low
> latency (audio)" application requires; it might even provide it
> all. Allowing I/O via hardware unrelated to the disk subsystem to
> proceed unhindered by disk I/O is good sense for all kinds of reasons,
> and would move Linux into the BeOS arena in one step.

That would be very nice indeed! :-)

> KURT would be nice for audio (and possibly MIDI) sequencing, but not
> necessary for the above solution to offer all of its own
> benefits. What exactly are Linus' objections to the KURT patches ?

I suspect there are similarities between some of Linus' objections and
mine...

Anyway, the main reason why I haven't even tried KURT yet (guess I
should) is the normal/RT mode idea. IMHO, no application should EVER
shut some parts of the system out. If there's free CPU time and work to
be done, get to it! Unless every part of the OS is completely functional
even when some tasks require hard real time scheduling, the system is
crippled. Not the way to go. Again, just MHO... (I might be missinformed
regarding the latest developments around KURT.)

> Aureality sounds interesting, but as est observed, unlikely to offer
> an environment conducive to interesting audio application
> development. SCHED_FIFO+I/O subsystems seems like a much more
> interesting approach to me.

What is an audio application?

This is what I have in mind anyway:

Your soft/firm real time application stays in user space, and use the
Audiality Client Application Interface, much like it would use OSS or
ALSA. (There will be compatible interfaces as well.) The big difference
is that it may use plug-ins running under the low latency engine as if
they were running on a dedicated DSP. You may still do "high latency"
processing in the application just as it's done now.

I intend to make it possible to run Audiality plug-ins in user space as
well, as that's the simplest and most efficient way to do off-line, non
real time processing. And it also means you can just steal the user
space plug-in host and use the plug-ins, if you really can't stand the
hard real time engine. ;-)


//David

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

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