[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: real-time threaded IO with low latency (audio)
Paul Barton-Davis wrote:
> If the subsystem approach was implemented, and your task is the sole
> task with SCHED_FIFO priority, there will never be a drop-out
> unless you exceed the CPU's capacity to generate audio samples.

That is, Linux turned into a hard real time OS. (Although not
necessarily a very low latency one!) Will this happen? Some people say
there are no such intentions...

> >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.
> I can do 5ms-latency real time FX processing (on a dual system, to be
> honest) with an interpreted language fronted by a complex GUI, using
> the current kernel. There are no dropouts if it runs SCHED_FIFO and
> you leave the GUI alone.

Pretty nice. :-)

> I consider the idea of a single-processor system replacing, say, a
> dedicated Lexicon rack unit or a Quadraverb 20, to be pretty
> silly.

Why, when it's a "simple" matter of fixing the real time scheduling? Off
course, cache misses and similar problems might suggest that latencies
below 3 ms shouldn't be used for efficiency reasons. That's a user level
choice, though: A little more CPU power, or extremely low latency.

> However, using a dual processor system, and binding a DSP-like
> thread to one of the processors has a lot of promise, and I'm pretty
> close to doing this once i get Tim's pset patches installed.

Well... Not what I would call a nice solution, but at least it's better
than external DSP boxes. And if it works with the current kernels,
great! :-) To me, it still looks like a shortcut to get around problems
in the kernel, much like my using RTLinux.

> >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.
> it depends on what you mean by "any defined time". if a SCHED_FIFO
> task is *not* running, and an interrupt occurs, then my sense of the
> kernel code is that you are *guaranteed* that it will be scheduled to
> run immediately. if the timer interrupts aren't frequent enough for
> you, you need some other source of interrupts. for these purposes,
> those of the soundcard itself work pretty well.

For the processing thread, it's a lot less than 5 ms. A lot less,
because signal processing is CPU intensive, and I want plug-ins to be
able to utilize more than a fraction of the available CPU power. There's
hardly no room for cathing up after a stall under heavy load, so this is
very important.

> running without SCHED_FIFO and a 5ms latency c/o the fragment size I
> request, more than 99% of all (10's of thousands of) write(2)'s to the
> soundcard on a mostly quiescent dual PII-450 system complete in 5ms
> +/- 0.05ms, measured using the pentium cycle counter (20nanosec
> resolution approx). With SCHED_FIFO, the numbers get even better. How
> does this work ? Because every time the soundcard interrupts us to
> tell us we had a buffer boundary crossing, the SCHED_FIFO (and even
> the SCHED_OTHER if the system is quiescent) task is woken up if its
> asleep and run immediately. Since I "asked to be woken" every 5ms,
> things keep rolling along very nicely.
> This is what I mean by latency not being a problem. The difficulty
> arises as soon the system is no longer quiescent: the kernel starts
> grabbing locks, and the SCHED_FIFO thread gets shut out for several
> msecs.

"Average latency" and "maximum latency" are two very different things.
And as we all know, it's a lot harder to fix the later one, let alone
providing guaranteed maximum scheduling latencies. Which is what is
required. A deadline is a deadline...

> This is bad for all of us. One reason why BeOS is a
> "multimedia" OS is that they recognized that the old idea of what an
> application "does" is wrong (i.e. many "modern" applications do 98% of
> their I/O to the video card and/or a soundcard).Lock-taking to protect
> what would have historically been universal (or at least heavily worn)
> paths through the kernel is now often just an impediment to timely
> execution. Yes, the scheduler still needs some global locks, as does
> the VM/MM system, but very else little else should be guarded in the
> way it is now. Everyone on l-k knows this - its just a big task to
> change it.

Yep... (When) will it be done, and are there any agreed on, acceptable
ways to solve all related problems? If there still are global locks that
may occasionally block out a real time process, it's not good enough,

If I knew it wouldn't just result in yet another patch that doesn't get
accepted by the non real time folks for performance reasons or whatever,
I'd be happy to join the effort of turning Linux into a high performance
multimedia kernel.

For now, I'll just work on my engine and plug-in architecture. It will
be moved wherever it can provide the performance I want from it. For
now, that's not Linux user space.

> >What is an audio application?
> Take a look at for my answer to that
> question.

That's a pretty nice answer! :-) That code will be nice reading, if you
don't mind. ;-)

> --p
> ps. sorry for misnaming your project.

It's a pretty weird one, isn't it? *hehe* (English isn't my native
language, so I can't really tell, I guess.) Anyway, it's pretty handy in
that it's unique. Have yet to find a service where that user name is
taken... ;-)


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

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