Subject: Re: [linux-audio-dev] LAAGA API Proposal
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Jun 15 2001 - 14:59:27 EEST
>> 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.
what makes the client run? you write:
>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)].
(note that this applies to nodes that generate audio as well as control
signals. i just happened to use a control signal example; C3 could
have been using an audio signal from C2 instead.)
how is the connection made? who and what defines the "driving app"?
since its an engine-free environment, nobody knows the overall state
of the graph except the user. so it is down to her to connect C2 to,
say, the audioio component, even though the connection serves no
apparent purpose (and in fact *does* serve no purpose at all once C2
is connected to something "for real")?
>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.
The idea of dependencies in the graph is precisely the root of this
problem, and its the one removed by adding an engine. Exposing the
idea of dependencies requires, as far as i can tell, that the user has
to consider LAAGA components as a kind of object quite different than
a conventional audio device; instead it becomes a mathematical object
where "failure to satisfy dependencies causes stalling in the graph".
i can't think of any audio components that fail to produce a signal
when they are incorrectly connected (though the signal may not be
whats intended).
here's a common situation at my home studio:
Hammerfall -> D/A converter -> mixer -> monitors
/
QuadraVerb FX -/
I frequently do not have the Quadraverb connected to anything.
It is really hard for me to imagine explaining to a non-audio-programmer
user why the equivalent configuration in LAAGA fails to produce any
output.
--p
This archive was generated by hypermail 2b28 : Fri Jun 15 2001 - 14:56:04 EEST