Subject: Re: [linux-audio-dev] LAAGA API Proposal
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Fri Jun 15 2001 - 11:36:43 EEST
On Thu, 14 Jun 2001, Paul Davis wrote:
> Here we get to the crux of my problem with understanding GLAME's
> "async" model:
Note that the following is not true for GLAME, but for my LAAGA approach
(which shares with GLAME the async. model and the explicit buffer
management) - GLAME has input and output ports, and you pay lots of
complexity for that in the code (of the "host").
> >> if there's no input, and the components are driven by input, how can
> >> the graph run?
> >
> >if you dont have input (no source) you dont have data to process and
> >nothing to output - there is no point in "running" the graph then
> >(of course it will be ready to run as soon as someone connects some
> >input)
>
> OK, I think I understand this now. Its because GLAME clients don't
> call getBuffer() where is no connection. The problem is that the
Yes.
> component will never be driven (the client never calls getBuffer(),
> and so never realizes there is work to do). therefore, components
There is no work to do :) If you have a client capable of producing
output without input thats fine - just produce output all the time.
But of course if you depend on input and there is no input there is
no point in trying to produce output at all. [You'll going to like
the following :) : You can "simulate" we-always-have-at-least-zeroes-
as-input by sticking a zero-outputting node before the node]
> downstream of its output(s) never get executed. this seems wrong. so
> either i don't understand how GLAME does this, or the approach doesn't
> work in a free-running system.
With async. operation each node capable of producing output (without
depending on input) can just do so any time it likes. Just syncronization
is done through input dependencies.
> There's a graph that i'd like you to explain if you could.
>
> (Cn: component N, audioio: some component driven by H/W)
>
> audioio:capture:chn1 -> C1 --------\
> audioio:capture:chn2 ---------\ ---> C4 ---> audioio:playback:chn1
> C2 -> C3---/
>
> C2 has no inbound connections, though some are possible. imagine it
> as, say, a MIDI translator that converts incoming MIDI into a control
> signal that affects C3. it could be connected to a MIDI source, but
> its not.
>
> assume also that C4 mixes its two connections into a single output.
[Answers are with the specific "functions" of the Cn's in mind]
> i don't see what drives C2, and thus i don't see how the second
Nothing drives C2, C2 will not execute and obviously not call
queueBuffer() on the port to C3. [C2 depends on its input]
> channel of audio ever shows up at the playback. in fact, i don't see
> how anything shows up, since: nothing will ever call queueBuffer() to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> send to C2, so C2 never runs. C3 never gets a buffer queued on its
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So C2 does not depend on this control signal? Then it may not syncronously
process this incoming connection! It instead needs to process without
the input from C2.
> second connection, so it blocks in getBuffer(). Likewise, C4 blocks
> calling getBuffer() on one of its two connections as well.
>
> it appears to me that this would stall the entire graph, which i don't
> believe GLAME does. so how do you handle this?
Handling of such cases is up to the implementation of the nodes. But
I should say that for "control signal" like stuff the async. model
is a lot more complicated than the sync. model (where you are driven
by the engine and at least "zero"es are passed around as syncronization
points - if I understand correctly, so in your above example, C2 would
just "implicitly" send out zeroes, driven by the engine). With the
async. model nodes without input are syncronization points themselves,
so a "control" node that f.i. does either put out zeroes or ones cannot
just put out zeroes all the time - because it is not rate-limited and
not synced to any other source [with GLAME and my LAAGA approach you
can (and should, for the sake of simple code and low-latency) provide
a syncronization to the control node by connecting it to the driving
app (just ignoring the input, but taking it as syncronization signal)].
So either you use [], or you need to implement "control" signals as
truely async. "messages" (which they are - they're asyncronously arriving
at the MIDI port of your computer) - of course you need then to use
select/poll to handle them async. in your processing nodes, too.
The network with the [] approach would then look like:
audioio:capture:chn1 -> C1 --------\
audioio:capture:chn2 ---------\ ---> C4 ---> audioio:playback:chn1
\->C2 -> C3---/
In which C2 now depends on input from audioio:capture:chn2 as
syncronization signal and always produces output (and C3 for the sake
of simple code can now really _depend_ on input from C2 without
problems).
So, if you have a dependency and the graph does not meet it, parts of
the graph may be entirely stalled. Solve this by avoiding dependencies
or by satisfying them.
Richard, who has now mentioned other problems whose solutions Paul will
not like...
-- Richard Guenther <richard.guenther_AT_uni-tuebingen.de> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
This archive was generated by hypermail 2b28 : Fri Jun 15 2001 - 13:01:37 EEST