Subject: Re: [linux-audio-dev] more audio client/server considerations (client acts as engine)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to loka 14 1999 - 21:22:04 EDT
>The idiotic case could be a plugin chain made up of 10 plugins, 5 of
>them running on app1 (the ones in the even positions) , and the other
>5 running on app2 (these in the odd positions), That would cause 10
>context switches for this chain. run a few of these idiotic chains
>and the scheduling overhead will ruin the whole CPU performance.
I certainly agree that this is a silly case, but I also think that our
system should *allow* for this configuration. I would hope that most
people would not use it.
>there could be two classes of clients:
>1)the client process the audio/event data and hosts plugins in his own
>thread, and sends only the final result (audio data / MIDI events)
>to the audio server which mixes toghether/routes the data from/to
>the clients.
>
>2) the client delegates most of functions to the engine,
>the plugins are hosted in the engine thread, that means
>audio data from the client is sent to the server and then processed by the
>plugin net of the engine, and then mixed/routed as with the clients in the 1)
>case.
i think there is a lot of confusion here about what an engine thread
is. *ANY* application can run an engine thread, not just a
"server". an engine thread is essentially just a framework for event
distribution, providing time information, and building/executing
processing nets made up of plugins (function calls).
anyway, this scheme should also work under our system, but again, i
would like to leave it up to the user to determine the configuration
that that adopt for any particular situation.
>IMHO it would be better to run all timestamp sensitive sensor tasks
>(MIDI input etc) in one single thread to reduce scheduling overhead.
>Or are there good reasons for not going this way ?
no, this is the way to go. the plural on "sensor threads" is my
fault. i meant it in a semantic sense, rather than an implementation
detail.
i imagine that an implementation would use something similar to the
GTK/XForms/Qt I/O callback registration systems, whereby you register
a function to be run whenever a certain I/O condition is true for a
given file descriptor.
void func (int fd, int condition, void *arg)
{
/* something happened to fd ... deal with it */
}
register_io_callback (some_fd, func, some_arg, IO_READABLE);
register_io_callback (some_fd, some_other_func, some_arg, IO_WRITABLE);
etc.
Need I add that Quasimodo does exactly this ? :)
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST