Subject: RE: [linux-audio-dev] LADMEA Prototype
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Thu Aug 16 2001 - 01:14:09 EEST
Right, time to catch up on some mail.
Yep, I understand in LAAGA the client *must* do something when the clock
ticks - this is fundamentally the way that LAAGA does things. It isn't
necessarily useful - for instance, a client listening to a MIDI port will
generate data asynchronously and will have no interest in the tick (its only
interest may be in timestamping the data). How would LAAGA stream such MIDI
data? The tick mechanism more-or-less works for audio (because of its
naturally fixed block size) but isn't even optimal there (e.g. when audio
can be calculated ahead-of-time or when block sizes vary or when the
application is in more than one process/machine). LADMEA doesn't stop you a
clock/tick when it's useful - it just doesn't force you to.
I don't agree with your fail-over (and "inactive") logic. In your example
where a sound processor fails, I don't see why LAAGA gives you an advantage.
If no audio is generated on a channel, there's not a lot that can be done
about it. I suppose the LAAGA analogy is that the call to a client does not
return fast enough. This will bring LAAGA to a standstill or glitch. In a
LADMEA arrangement, the exchange has enough information (for streamed audio)
to spot the fact that data delivery is late and act intelligently, either by
stopping proceedings or generating a silent audio stream as a surrogate (or
freezing/glitching if the implementation prefers). In your example with the
patchbay, there is nothing a patchbay itself can do if the audio isn't ready
anyway, within a LAAGA or LADMEA framework. Incidentally, when all is
working the push model means that the patchbay can generate its output frame
immediately as soon as (but no sooner than) all its input data has arrived.
Couldn't be any sooner, no context switch required (for the in-process
case).
It is not true that "*every* kind of client has to do the same kind of check
as the hypothetical patchbay does on its ports-at-which-data-arrives". For
instance, a MIDI port listener will never need to (no inputs). A MIDI port
output will never need to (just output anything fed to it). An audio input
or a scripted software synth will never need to (no inputs). An audio output
will never need to (just output anything fed to it). An in/out audio
processor will never need to (just process inside sendTo()) and send back to
the exchange - doesn't need to know if its running realtime or not. Checks
*do* have to be made where there is more than one input required, e.g. in a
patchbay, FX process with real-time controls or combined MIDI/audio
sequencer or where there is some external binding to realtime (e.g. a
realtime GUI component). These checks are hardly onerous however ("if
(audiochanframes > 0 && controlchanframes > 0) {...}") given the flexibility
provided.
This approach can be mediated by the exchange - a clever one can observe
that two network machines are drifting out of sync and add or delete samples
to fix this. As far as I'm aware, LAAGA would need a whole new layer to deal
with this. I'm attempting both steps in one.
The comments about buffer management are fair - I missed this out for
simplicity. I think everything else present is necessary - adding buffer
management isn't, although it could provide a small optimisation in some
contexts. I'd prefer not to put anything in at this stage to keep the weight
of the API down - it's easy enough to add later. I don't actually think this
optimisation (or the run/run_adding kind) is especially significant in this
context - LADMEA is intended primarily for inter-app communication, so
zero-copy isn't nearly such a priority as in LADSPA IMHO.
Thanks for the feedback,
--Richard
-----Original Message-----
From: owner-linux-audio-dev_AT_music.columbia.edu
[mailto:owner-linux-audio-dev_AT_music.columbia.edu]On Behalf Of Paul Davis
Sent: 14 August 2001 00:59
To: linux-audio-dev_AT_music.columbia.edu
Subject: Re: [linux-audio-dev] LADMEA Prototype
>Very fair point - sync is a difficult problem and I'm only 90% sure it's
>solved here.
>
>I should have mentioned this more in the earlier post - there is nothing to
>stop clocks ticks from being delivered by a clock generator client (this
can
>be generalised out to include SMPTE and suchlike)
This isn't anything like the kind of clock tick I was describing when
I wrote:
>Summarised, thats because to work in the way expected by users (and
>quite reasonably so IMHO), the "network" needs to be driven by a
>uniform, overarching "clock" that ticks universally for every node. A
>node may choose to do nothing on a tick, but it must be "called" and
>return synchronously at each tick. Any system based on a model like
The kind of click I was referring to is an imperative instruction
delivered in the appropriate order to every node in the graph. The
instruction means "do something now". The node *must* do something
right then, although doing nothing qualifies as doing something. This
has ...almost... nothing to do with sync. Its at a much more basic
level - the basic driving force behind the entire system. But read on ...
and I've been anticipating
>clocks built into the exchanges themselves (and delivered through a channel
>like any other data). The fact that the API doesn't specify the mechanism
>hopefully(!) doesn't prohibit it - in fact this should allow more
>flexibility.
>
>Could you give me some examples where this would be a problem? I've been
>dealing with the abstract for the past two days and some examples of the
>concrete would be helpful!
Sure. The case we discussed in connection with GLAME is fairly simple.
Imagine a soft synth connected to a patchbay that then feeds some
later stage in a processing network.
Now connect some other "device" to the patchbay. Turn this other
device "off" so that it never calls "sendToExchange".
Now run the graph. In the model that GLAME uses, the patchbay will
stall, and the output of the softsynth will not appear on the audio
outputs. Why? Because its going to wait for data to arrive on the
port/channel/whatever that the "inactive" device is connected to, and
none ever will. Thats because GLAME uses a pull-to-me model, where
each node blocks waiting for data from its antecedent nodes.
By contrast, you use a push-to-whoever model as you're proposing, then
the patchbay only responds to data explicitly sent to it. if so, we
have what a slightly odd model. the patchbay presumably has to check
that there is or is not data waiting at the port with the inactive
client. But for there to be such a flag implies that the inactive
client does actually do something, no matter how small, to indicate
that the port is in some condition where the patchbay may continue.
So now, "inactive" does not mean "do absolutely nothing", but "mark
all relevant ports as <whatever>".
I consider this slightly wierd. Wierd in part because *every* kind of
client has to do the same kind of check as the hypothetical patchbay
does on its ports-at-which-data-arrives. This can't be stuffed in a
library, since what it will do when there is no data may vary
significantly depending on the operation of the node. This now means
that readFromExchange (or whatever it was called ... :) has to be able
to indicate this condition, which leads to all kinds of odd
complications.
LAAGA/JACK avoids this completely. What you get when you call
laaga_get_port_buffer() is an address of memory that contains the data
you should see for that port. its always the correct data, and there
is never any notion of "nobody posted anything here".
> 1. Find or create the channels to work with and request the data types
>required.
> 2. Activate (some negotiation may occur to agree sample formats etc).
> 3. Receive incoming packets and write outgoing packets.
This is where we differ. I don't want a model in which there is any
explicit model of data exchange. The clients should be able to be
written as though they are writing directly into memory, because
otherwise it becomes rather difficult to use zero-copy techniques
which are totally practical from a theoretical point of view, and also
with LAAGA/JACK's model.
In the "sendToExchange" model, there is no mechanism suggested by
which the client can ensure that the "data" address passed in is in,
say, shared memory. No implementation can provide zero copy unless it
also provides buffer management. Thus, you end up with the client
using its own local memory buffers, then passing the address to
sendToExchange, which then requires a data copy and the resulting
cache lossage etc.
Furthermore, you can't efficiently avoid the whole run/run_adding()
nonsense that so bedevils LADSPA/VST and others, which LAAGA/JACK does
rather elegantly, if I say so myself :)
Comments?
--p
This archive was generated by hypermail 2b28 : Thu Aug 16 2001 - 01:18:33 EEST