Subject: Re: [linux-audio-dev] the alternate API for LAAGA: its problems
From: Francois Dechelle (Francois.Dechelle_AT_ircam.fr)
Date: Thu Jul 05 2001 - 11:16:57 EEST
Paul Davis wrote:
>
> as alluded to in a previous message, there is a bit of a serious
> problem in trying to provide a "legacy application" (i.e. most of
> them) with an easy way to use LAAGA without a more significant
> restructuring (my motivating example is MusE).
>
> the plan was to provide a couple of file descriptors; the application
> would need a small change to its code - instead of calling select/poll
> on the audio interface file descriptor(s), it would use the first of
> these two fd's. when the fd was ready to read, it would read an
> unsigned long from the fd, then it would do its "process" thing for
> that many frames, and then it would write the same value to the second
> fd (thus driving the next node of the graph).
>
> this is all very nice, and fairly simple. however, it takes over
> from the LAAGA library one of the tasks currently done there. no big
> problem with that, but its very connected with the other tasks. in
> particular, when the graph is reordered (because of
> connecting/disconnecting ports), the library takes care of that too
> (it closes and reopens some file descriptors).
>
> the problem is that the main application thread doesn't know about
> this; it will be asleep in select/poll.
>
> so, what to do? well, one obvious thing is to note that select/poll
> will return with an error set for that descriptor; the application can
> simply note this, re-call laaga_get_process_start_fd() (or whatever
> its called in the end), and go back into select/poll.
>
> but this is rather ugly. without better checks, the application could
> miss a genuine error (e.g. the LAAGA engine has crashed/exited). once
> you start to add better checks, it gets to look as if the application
> is doing a lot of work on this issue. (on the plus side, it would
> require authors to check for POLLNVAL and its select(2) equivalent,
> which is often not done).
>
> the heart of the problem is that the fd used to drive the graph is
> *not* the one used to tell the client to handle a graph
> reordering. thats because the fd used for "event delivery" (e.g "the
> graph has been reordered") needs to be a duplex connection between the
> client and the server/engine (duplex because the client needs to
> notify the engine that its finished handling the event). the graph
> driving fd's are one-way connections between, variously, the
> engine+client, 2 clients, or a client+engine.
>
> so, we have a client thread handling event notifications on the duplex
> fd, and the application's own select/poll loop handling "graph process
> start" notifications on the other.
>
> what, if anything, would be an acceptable way to handle this? ideas
> are very welcome, particular since i don't want anyone to have to do
> as much work as might be necessary for MusE to enable it to become
> LAAGA-compatible.
>
> --p
Why not using a signal ? This signal would interrupt the select(), making
it return with errno==EINTR. You can then retry the select() after getting
the new file descriptor. This preserves also the select/poll returning
an error for true engine errors, such as engine crash.
The problem is that this leaves some code to be handled by the application
code and not the library, as in:
if (select(n,&rfds,&wfds,&efds,0) < 0) {
if (errno == EINTR)
laaga_fd = laaga_get_process_start_fd();
else
exit(1);
}
fd
This archive was generated by hypermail 2b28 : Thu Jul 05 2001 - 11:18:31 EEST