On Fri, Jun 08, 2001 at 07:39:01AM -0400, Paul Davis wrote:
> the example given was a simple one that does not use the in-process
> capabilities. most applications will not want to use the in-process
> model because of the way it complicates their GUI design.
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 :) )
> 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...
> you call audioengine_open() in either case. it is, however, a design
> decision made by the application author whether to support the
> in-process model since this is a potentially a source of a lot more
> work for the author.
Ok I get it.
> 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?
> >* provide a way for the audioengine client side to hook up to your own
> > main loop
>
> you cannot have more than 1 main loop in a thread. thats what
> callbacks are for. the engine ensures that the callbacks are executed
> at the right time.
I know that... What I was talking about was some means for the
client-side server communication code to hook up to the client's main
loop (i.e., something like provide an fd to wait for and ask that
client calls some callback when there's data) in order to eliminate
the need for an extra thread. Not a good idea at all, since it would
expose implementation details and be generally painful.
Simon.
