Re: [linux-audio-dev] LAAGA API Proposal

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

Subject: Re: [linux-audio-dev] LAAGA API Proposal
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Fri Jun 15 2001 - 15:08:47 EEST


On Fri, 15 Jun 2001, Paul Davis wrote:

> >> 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")?

Yes.

> >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

Yes.

> 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.

So whats the point in having it connected to the mixer then? It just
adds noise!? Whats the point in running the app for the Quarda (which
is needed to create the connection in the first place) if you dont
use it?

> 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.

I can see your problem with my approach and I cant offer you a solution
you'd be happy with.

Richard.

--
Richard Guenther <richard.guenther_AT_uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/


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

This archive was generated by hypermail 2b28 : Fri Jun 15 2001 - 15:08:19 EEST