[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: [linux-audio-dev] the alternate API for LAAGA: its problems
From: Paul Davis (pbd_AT_op.net)
Date: Thu Jul 05 2001 - 08:19:30 EEST


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


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 - 10:55:51 EEST