Re: [linux-audio-dev] LADMEA Prototype

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

Subject: Re: [linux-audio-dev] LADMEA Prototype
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Aug 14 2001 - 02:59:16 EEST


>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


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

This archive was generated by hypermail 2b28 : Tue Aug 14 2001 - 02:58:07 EEST