Subject: Re: [linux-audio-dev] Realtime
From: rob (rob_AT_kaybee.org)
Date: Wed Jun 28 2000 - 06:33:47 EEST
> 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.
how do you mean protected components? one of the ugly things
about creating an rt module is that a stray pointer or miscalculation in
timing and your box takes a trip into the weeds which can be costly.
i've been interested in using a pc dedicated to synth/sampling
duties for a while. the scheme i've been working on goes something like
this: a userland program would read the config files, and setup shared
memory for the samples etc, and start the rt modules (io and mixing).
then you'd have to poll the input (midi, serial, ethernet) and
perform the mixing and device output.
it seems like most of the things one would like to be real time
are the hardware devices. i believe this would require them to
be written specifically to be useful in the rt modules. is there any way
around this?
ideally it would be nice if the rt module could schedule specific
tasks to run inside the linux thread so that one could have full access to
services. this seems unrealistic though, since the linux kernel could be
blocking or in a critical section.
rob
>
> 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.
>
----
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
This archive was generated by hypermail 2b28 : Wed Jun 28 2000 - 07:07:15 EEST