Subject: Re: [linux-audio-dev] LAAGA API Proposal
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Jun 13 2001 - 19:52:07 EEST
>Ok, we seem to know what both approaches do and what advantages and
>disadvantages are (but we dont agree on them). So I think we either
>need input from some other guy or we can stop discussion.
More or less true, I agree. But not quite :)
>Perhaps I have time to do an implementation of my API, probably calling
>it something different than LAAGA - ASCA (Application Stream Communication
>API). Competition is always good.
I don't think its good here. In fact, I think its terrible. We want as
many applications that can benefit from sample-synced interaction to
do so. Providing 2 or methods of doing this is not going to help that
happen, in fact it will make it less likely to happen.
>> How does a 3rd party behave (both visibly and code-wise) when a user
>> tries to make a second connection using an object that is already
>> connected and doesn't do mixing?
>
>The connection is refused. So the user has to insert a mixing plugin
>inbetween (if the desired effect was mixing - which is intuitive, but
>obviously not the only possible effect).
Actually, its not intuitive at all. When I route signals from a mixer
strip on either a digital or analog mixer onto a bus, there is no
additional "node" between the strip (which has gain control etc.) and
the bus.
Your model requires that either the bus be able to handle mixing
(which is OK), or that the person uses an additional mixing node
(which I don't think is OK).
>Ah, ok - this simplifies (a little bit) buffer handling and processing,
>but makes feedback with fifo size != fragment size impossible (you said
>that already, if I understood right).
Correct. Thats the consequence of any sample-synchronous system with a
block size of more than 1 frame.
If LAAGA is not sample-synchronous, then it doesn't really accomplish
the goal it sets out for.
>Well, queueBuffer() does what it is called - it just queues the buffer
>to the recipients buffer lists. Any recipient blocking on its (empty)
>buffer list gets woken up (easy to implement with unix pipes or the
>like, writes for queue(), blocking (or nonblocking for poll/select
>like operation) reads for get()).
except that you have to do one poll/select or read for every get. this
is no so good. if i wake up from poll because one buffer has been
queued, i don't know that the other buffers are ready yet. so i have
to go back into poll again until they are all ready. this won't scale,
i think, which is why i prefer a model in which we don't wake up the
client until we know (because of graph execution order) that all of
its buffers are ready.
>> this is what bothers about your "async" model. it sounds as if other
>> components could potentially use queueBuffer() to signal a component
>> at any time, making it very hard to write the code so that it works in
>> a low latency situation. in my system, whenever a component is
>> running, it already knows that all of its buffers are ready and that
>> it will not interrupted or resignalled or whatever during its
>> execution.
>
>Humm - so you cant handle "independend" graphs without being forced
>to sync them? I.e. no SMP benefit at all?
If there are subgraphs within the graph that are not connected to the
rest of the graph except for an input, then yes, we could get SMP
benefit. This just requires a cleverer algorithm (one that GLAME and
many other systems have implemented already) to partition the graph.
However, i don't imagine that in many cases such partitioning will be
possible because of the kinds of connections a user will create. If
you're mixing incoming audio data with a stream from a softsynth,
processing the result with an fx unit, sending the result to an HDR
and also back to an interface for monitoring, there is no way to
partition the system at all except on a per-channel basis, and that
will probably be impossible because since the units are not mono.
>> yes, i know about that. i've talked to the pthread author about this,
>> and he considers that version to be broken. kernel 2.2 and above
>> support the "RT" signal set, so I don't consider this much of a
>> problem.
>
>Err - so you're Linux only and dont support BSD or other weird
>architectures.
No. I just know that the reason linuxthreads with SIGUSR1/SIGUSR2 is
"broken" is that it violates POSIX by using these two signals to provide
POSIX functionality. any pthreads implementation that does this
violates the POSIX requirement that these signals be available for
applications to use.
This is another reason I dont like signals - signals
>and threads dont mix portably, with read()/write()/select() you have
>maximum portability (even NT might support such style of operation).
>But of course using signals is implementation dependant and no
>requirement for the API.
Yes, your right, they are not very portable. But read/write can't work
without horrendous complexity unless you have fd passing, which is
also not portable. But you're also right that its not part of the API,
so we don't have to worry too much.
>> you don't need async for this to work. if there is a feedback loop,
>> there is no correct order for the graph execution, so you merely
>> need a guarantee of a particular order for as the loop exists.
>
>There is a correct order - for the echo example, the first plugin
>to execute is the delay plugin which needs to put out a set of zeros
>to be able to start processing in the other nodes. So for sync.
>operation you somehow magically need to detect that delay can produce
>output without having input first.
once again, this is a free running system. a unit with an output port
generates output at all times, whether they have connections or
not. the delay line produces silence before there is anything
connected to it. ergo, there is no correct order. if you run the input
to the delay first, you get one effect. if you run the delay first,
you get another. all that matters is that you never change the order.
--p
This archive was generated by hypermail 2b28 : Wed Jun 13 2001 - 21:22:07 EEST