Re: [linux-audio-dev] the alternate API for LAAGA: its problems

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] the alternate API for LAAGA: its problems
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Thu Jul 05 2001 - 19:49:31 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.

What about to pass a special number of frames to client and then ask to
it to call a laaga library function when it receives that?

Would not solve everything?

-- 
Abramo Bagnara                       mailto:abramo_AT_alsa-project.org

Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy

ALSA project http://www.alsa-project.org It sounds good!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 05 2001 - 19:51:21 EEST