Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Jun 08 2001 - 14:39:01 EEST
>Is the intention to create a One Audioengine implementation, with
>accompanying client library, or is it just a specification of an API
>that can have many implementations in the end?
Its an API that could have many implementations. I will be posting a
complete implementation in a few days.
>> However, we need to support out-of-process too since it will work even
>> for <3msec latencies in almost every case. Thats why the audioengine
>> API I am in the midst of proposing is independent of whether or not
>> the "client/plugin" is in-process or out-of-process, though I have to
>> admit to a bias toward out-of-process right now, since it solves many
>> problems without introducing many new ones.
>
>How does the in-process case work? I assume there would be some
>plugin_init() function to look for in the shared object that is not
>specified yet. But then what happens? Looking at main..
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.
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.
>Otherwise I don't understand how it's working. How would a regular
>audioengine_open (client_name, ...) know if it's in process or if
>we're supposed to connect to a server etc..?
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.
>And, for the MP case... Is the specific IPC technique used not
>relevant to the API, do you say? How does that work? I mean, say
>that named FIFOs are used for sync (shm for the actual data). Then,
>as it looks like from main() here above, audioengine_open needs to
>pretty much create its own thread to wait for an fd, is that right?
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
before passing control along to the next client or back to the
engine. i'm using a combination of shm, sockets and kill(2) for my
implementation.
but none of this is visible to the client. once they call
audioengine_open() and provide the callbacks, the right thing happens
without anymore work on their part.
>* 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.
>> some_list_type_t *audioengine_get_ports (const char *port_name_pattern,
>> const char *type_name_pattern,
>> unsigned long flags);
>
>What kind of regex would be used? Actually, is that necessary... Why
>not just return all the ports and let the user program filter as
>necessary?
The thing is, you can use NULL if you want to filter them
yourself. The implementation doesn't have a linked list of ports that
can be used by the client, so we have to create a new data structure
to return the information anyway. I thought that adding the capability
to filter within the call was more efficient.
--p
This archive was generated by hypermail 2b28 : Fri Jun 08 2001 - 16:33:15 EEST