Re: [linux-audio-dev] Audio engine stuff

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

Subject: Re: [linux-audio-dev] Audio engine stuff
From: David Olofson (david_AT_gardena.net)
Date: to helmi  17 2000 - 18:44:46 EST


On Thu, 17 Feb 2000, sbenno_AT_em.gardena.net wrote:
> > Hmm.. hey, no comments about inserting plug-ins to the engine on-the-fly?
>
> I see this not as a big deal:
> just use one thread with non RT-privileges to load the plugin() on the
> fly via dlopen() , mlock() the plugin-code , and then call the
> instantiation code.
> When done, notify the main engine (running with RT privileges) that
> the plugin is ready for execution.
> At this point you are now able to call any functions of the plugin
> without nasty delays.

Hmm... Yes, this seems to fit well with the API variant I'm working
on now. Since the initialization is done via the event system (the
same interface used during processing), any sync issues and the like
are concentrated to the event system - which is designed to handle
that kind of stuff anyway. The plugin in the "non-RT" init thread
could actually be connected to the engine *before* it's running in the
engine's process. (Don't ask me if that's useful in this situation!
It's just a free bonus, being able to do that kind of stuff... You'll
most likely want the RT/non-RT gateway anyway, as that's how you
communicate with the engine.)

BTW, I've managed to write some docs that could perhaps explain some
of the FAQ re the MuCoS plugin API. They're more of "brainstorming
output", and may not be very structured, but they're probably more
informative than nothing at all! :-) I'll put them on the site ASAP.

Oh yeah, new ideas again... I've discovered that the dynamic size
event allocation system can actually be more efficient than a pool of
fixed size events.

I'm also thinking about putting the array events (multiple property
changes/commands in a single event) back in - for performance
reasons. I still can't tell if it's really worth it, or if it's just
pointless complexity.

Finally, I think I have found a pretty simple way of eliminating
nearly all "active" event sorting/routing in the engine. Basically,
it's about having input channels 1..N and output channel 1..M on
plugins, and then use virtual channels to connect them.

I think I'll post some interesting parts of the documents, in case
you don't have enough to do already... ;-)

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST