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: yodaiken_AT_fsmlabs.com
Date: Wed Jun 28 2000 - 05:07:49 EEST


On Tue, Jun 27, 2000 at 10:22:26PM +0200, Benno Senoner wrote:
> 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.

RTLinux is now available as RPM. I agree that it would be easier to have
it on distributions, but it's not a very hard problem to include
a working kernel with a CD.

> (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)

Some of them are about ready.

>
> - 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.

I don't see why it would require a "complete rewrite".

>
> - 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.

That's not really correct. It is quite easy for RTL to ask Linux kernel or
user applications to allocte more memory. I will send you an example
if you like.

> 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)

You are. RT components cannot directly alloc memory because there is
a chance in such allocation that there is not enough memory and the
requestor will suspend. But there are many methods of allocating via
Linux.

> - 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.

RTLinux modules are like drivers -- if you can accept drivers in kernel
space, you should not have a problem with RT components.
But if protected components are necessary, we can do that too.

>
> - 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.

To use fpu in a RTLinux thread you must write the following code

           pthread_setfp(thread); /* mark the thread as using the FP */

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

Yes. This is abosolutely correct -- but realtime is harder than nonrealtime.
BTW: you can use gdb on RTLinux threads.

> 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")

The interesting, at least to me, question is whether one can structure
a synth/sampler as a relativley simple RT component and a more
complex user space component that work together.

> 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 ?

Well, I am very interested in the question of whether the RTLinux model
of breaking a RT application into tiny RT parts and user parts can work
in the audio domain. Speaking with the authority that comes from
knowing absolutely nothing about the field, it seems to me that at least
some apps can be structured as
         RT part:
              do{
                 samples
                 computes using table share with user code
                 outputs to device and to shared memory
                 check commands, if any, from user app
                 }

So if there is some way we can help to make this or a better way of using
RTLinux convenient for developers, I'd like to do so.
And if Linux kernel user programs offer a better avenue, that's not
something that will make me upset.

> 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
> --

-- 
---------------------------------------------------------
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.


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

This archive was generated by hypermail 2b28 : Wed Jun 28 2000 - 06:02:06 EEST