Re: [linux-audio-dev] silent for a while

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

Subject: Re: [linux-audio-dev] silent for a while
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Jun 24 2001 - 17:37:22 EEST


>Ah, what a beautifully peaceful week ;-)

Sorry to ruin the prospects for the next one. 1700 miles later, I'm
back. Bwahahahahaha :)

>However I'm now a bit puzzled what LAAGA attempts to achieve - as far as I
>can see, any LAAGA application has to hand over its control logic to the AES
>engine? Possibly I've missed where the `interface point' is in the code, but
>this seems somewhat over-prescriptive.

My prototype implementation of a LAAGA system is based on a callback
model, which I have become convinced is the only correct way to do
such a thing. Applications and/or dynamically-loaded plugins provide 1
or more callbacks that will be executed at the right time. They are:

     the "process" callback: called when data should be collected or
          delivered to ports
     the "buffer size" callback: called whenever the maximum number
          of frames that the "process" callback will be asked to
          handle changes
     the "sample rate" callback: called whenever the sample rate of
          the system changes

The application has to be written in an event-driven style, just as
any GUI code is these days. However, the main "event loop" is either:

   * for applications: running in a separate thread using code
          from the library
   * for dynamically-loaded plugins: running in the audio thread
          of the engine (which is where the plugin's callbacks will
          be executed too)

So yes, your application no longer controls the timing of audio
delivery, but its free to do whatever it wants within the "process"
function. For example, a simple audio file player would simply keep
track of which frame its currently reached, and whenever the process
callback is made, it would deliver the specified number of frames to
its port(s). If it is to be able to run in an RT LAAGA system, it will
need to do the usual stuff like add a memory buffer between the disk
i/o and the process callback, but thats not part of the LAAGA API or
spec - if it takes too long to get the data, the engine will simply
remove that node from the graph.

>What software would use this API? What changes would have to be made to
>Csound to allow a MIDI sequencer to drive it while feeding audio into
>Ardour?

Csound cannot (easily) be changed to work like this; as several people
on the Csound list, the changes are also needed to get Csound to be
usable as a VST plugin which many people would like very much.

> How would the link be set up? This, to me, is the kind of basic
>challenge that an `application glue' framework needs to meet.

There are at least two models supported by the API I've presented. An
application can present its own connection UI, allowing a user to
specify connections between ports. It can query the system to discover
all, or some subset, of existing ports, and it can request
notification of port creation/deletion. Such an application (ardour
would be an example) would also "lock" its ports so that no other
application could modify the connections so made.

However, its also trivial to write a 3rd party application that does
not but provide a UI for port connectivity. This application could
present any of variety of metaphors/images about the existing ports;
it could use a heirarchical presentation, use patchcords, buttons,
names, whatever it chooses. In the end, it will make the same call
to the LAAGA library that an application in charge of its own
connections would.

> As we
>discussed when we met up, isn't an ALSA-like API better suited to this? How
>would aRts do it?

I believe that ALSA's API is completely inappropriate for this task,
because it doesn't use a callback approach. From what I know of aRts,
its not possible, without drastic modifications to aRts, for it to
satisfy low latency requirements because of some basic assumptions it
makes.

I would be quite happy, however, if something like LAAGA became part
of alsa-lib.

>next week or two. I do think we're better off abstracting away from
>OSS/ALSA/aRts or suchlike but I'm not sure we're doing it the right way.

I believe (as I've said several times) that OSS and ALSA are Hardware
Abstraction Layers, and not anything close to a model of a generalized
design for connecting multiple applications/plugins in a low latency
system. They work well or even very well for applications that are
interacting with audio h/w, but not, IMHO (and that of Abramo, too, I
believe) for the purposes outlined by Kai for LAAGA.

aRts is closer, but doesn't handle low latency adequately and
would really be a completely different program if it did.

>My instinct is that the existing framework deals with two issues - how to
>handle audio/data exchange and how to specify network topology. These seem
>to be orthogonal concepts to me and better separated.

One purpose of LAAGA is to present a highly simplified API for
handling audio so that audio/data exchange becomes easy(-ier). One
consequence of that is that network topology is reduced to a single
concept: port (dis)connection. Since data is exchanged via ports, it
seems hard to disentangle the concepts completely. I prefer to focus
on the simplicity of the API: two calls to connect and disconnect a
pair of (named) ports. Everything else is hidden within the LAAGA
implementation.

--p


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

This archive was generated by hypermail 2b28 : Sun Jun 24 2001 - 17:38:08 EEST