Re: [linux-audio-dev] Realtime

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Realtime
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Jun 27 2000 - 23:22:26 EEST


Hi,
on this list, we (minly David Olofson) investigated using RT Linux for low
latency audio for some time, but came to the conclusion that it is not the way
to go.

here some of the reasons:

I ma speaking about multimedia apps in general which comprise audio , MIDI and
video and possibly other fields.

- RTLinux will not spread well enough on the desktops thus by requiring
RTLinux for your realtime-audio-app, you are lowering the potential
target userbase in a huge way.
(One solution would be to convince redhat, suse, debian, mandrake and
all the others to ship RTLinux instead of Linux but that would he hopeless
as well)

- multimedia apps need to interact with multimedia devices (soundcard,
framebuffer, MIDI interface etc) , thus using RTLinux would require a complete
rewrite of all these drivers.
no chance.

- memory usage: audio (and multimedia apps) need tons of memory,
often dynamically allocated during program execution.
David told me that RTLinux can only manage a certain amount, fixed at module
insertion or so.
Thus making the efficient managing of large amounts of memory quite difficult.
(eg if I want to load a 100MB WAV file, I want to alloc the memory just before
loading, then load the file, do my RT stuff on it, and then free() it , so
that other apps can take advantage of the 100MB of RAM)
(correct me if I am wrong)

- memory protection : in userspace I have full memory protection that means
in the case of a bug I get a segfault at maximum but no crash.
I don't know if RTLinux provides memory protection right now, but last I
checked there was not support for it.

- under RTLinux you have to take special measures in order to ulitize the
 FPU , since multimedia apps make heavy use of FPU instructions, this can
become a problem.

- developing (and debugging especially) an application for RTLinux is not as
easy as writing a simple userspace application.

As we all have seen, a simple userspace application which
(given you run it on a kernel with low latency patch)

meets the following criteria:

-runs SCHED_FIFO
- mlock()s all memory areas meant which are accessed by the RT theread
- does not call "non-deterministic" syscalls which are the ones which might
block for an undetermined amout of time like disk I/O.
 
can deliver latencies down to 1msec which is more than adequate all
multimedia apps.

for example in the audio case a loop like
while(1)
{
  do_processing()
  write() block to soundcard
}

it completely deterministic, since the do_processing() does pure math
( eg DSP stuff) and the write() to soundcard returns within a determined
amount of time (samples are transfered to the soundcard's RAM either via
DMA or via memory copy).

That is basically what "latencytest" does.

RTLinux of course delivers better response times than a linux+lowlatency.
(I believe in the range of 20-40usec), but that is just overkill for multimedia.
Why ?
Assume we want to achieve 0.2ms latency which is about
38samples per run.
Assume we want to run a chain of 10 DSP plugins on each block.
We will spend more time in algorithm setup, procedure calling overhead
cache misses (due to the high scheduling frequency) etc than doing useful DSP
work. (just like it is inefficient to send GB of data using 64byte TCP frames)

So since the "pratical" (those which do not trash performance due to
the above, unavoidable sideeffects) latencies ( 2ms upwards) are achieved
by the lowlatency kernel too , I prefer to go the easy way, and
the chance is bigger that Linus will accept some form of lowlatency patch,
than integrating the RTLinux patch within Linux.

I am not against RTLinux, I think it is wonderful and works well for the
fields it was designed for (hard realtime with <50usec response time needs),
but what I want for future linux multimedia is good performance , ease of use
(for both users and developers) and maximum possible widespread.
That means install your favorite linux distribution, install your
realtime audio app, and then make sound.

Plus speaking from a developer POV, we should not let it happen
that complete and complex synthesizer/samplers run within
the processor's Ring 0 , as it happens under Windows right now.
(they are forced to do so in order to get some realtimeness out
from that so called "OS")

So yes, there might be some very specialized applications which would
require VERY low latencies (down to the sample level or so) requiring
and RTOS, but the other 99.99% of cases can be solved with the userspace
solution, easing life of all involved parties.
 
Victor, your thoughts ?

Benno.

On Tue, 27 Jun 2000, rob wrote:
> hi,
> from what i understand the biggest barrier to the use of RTLinux
> for audio is the need for special drivers to support it and the lack of
> access to system services.
> i could see using a realtime module which would do the mixing via
> shared memory and perhaps schedule the linux kernel to do disk IO. i had
> started working on such a module which was based on a usermode sample
> playback engine i had already made but found the beta RT 2.2 patches to be
> a bit buggy at the time.
> currently, much of the work people are doing is focusing on using
> Ingo Molnar's low latency patches. however, Linus, et. al, have raised
> issues with them and won't integrate them into the mainstream kernel in
> their current form.
> i'm glad to hear that rtlinux is now working under PPC, and thanks
> for dropping the list an email.
> rob
>
> On Mon, 26 Jun 2000 yodaiken_AT_fsmlabs.com wrote:
> > We've been getting a lot of inquiries about RTLinux/Audio recently (esp.
> > from Australia for some reason)
> > and I'm curious whether people on the list are using it. If not is there
> > anything we can do to make it easier to use ? Is so, I'd really
> > like to see what people are doing.
> >
> > FYI: Linux PPC now runs the RTLinux system without needing a patch.
> > PowerPC performance has been quite impressive.
>
> ----
> Rob Melby
> Georgia Institute of Technology, Atlanta Georgia, 30332
> uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
> Internet: rob_AT_kaybee.org, gt4255a_AT_prism.gatech.edu

-- 


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 27 2000 - 23:54:18 EEST