Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Jun 09 2001 - 06:28:58 EEST
>I would say that for example a softsynth can (and therefore, should),
>use the in-process model, because it should have that separation
>between the "synth machinery" and the GUI anyway; control messages
>through MIDI or similar. (At least that's how I think a softsynth
>should be designed, good thing we have a choice I guess :) )
yes, many people think thats how they should be designed. however,
there are a variety of ways of enforcing the separation of "engine"
and GUI, and some of them are not easy to use in the case of multiple
processes. hence, i don't wish to force an in-process model, certainly
not now that we've shown that out-of-process can work.
>> for the in-process case, the "application" is just a little stub which
>> contacts the engine via a socket and requests that it load a
>> specified shared object.
>
>Some need for extreme carefulness wrt security there...
given that the engine will nearly always be running either root uid or
the CAP_RESOURCE capability, any system with a running engine must be
considered to be a massive security hole. i don't consider this too
much of a problem at this time. no doubt we'll have to pay some
attention to it later.
>> yes, thats what it does in the out-of-process case. the thread waits
>> for a "message" from the engine, and then calls the correct callback
>
>What if the client wants to control scheduling properties of this
>thread? Unneccessary?
more like unacceptable. the scheduling properties of this thread need
to be determined by the needs of the engine. the client has zero,
repeat, zero control over this stuff. its job is to provide callbacks
that supply and/or consume audio data to/from its ports, not to worry
about details like this. audioengine_open() takes care of ensuring
that the thread has the appropriate scheduling properties given those
of the engine instance.
--p
This archive was generated by hypermail 2b28 : Sat Jun 09 2001 - 08:09:31 EEST