Subject: [linux-audio-dev] Re: high level laaga
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Fri May 11 2001 - 16:17:48 EEST
Paul Davis wrote:
> 0) Establishing common formats
>
> Things get much more tricky, and much more wasteful, if the
> components in a LAAGA setup do not use a single format to represent
> audio data.
This unfortunately limits the solutions space and I think this is a big
mistake designing a general purpose infrastructure.
> 1) Abstracting complexity
>
> Even with alsa-lib to manage things for us, interacting with
> audio hardware is a non-trivial task in all but the simplest
> application. It is not sensible for every audio application author
> to have to deal with this over and over again. So LAAGA also seeks
> to present a vastly simplified and abstracted interface to
> audio hardware. One possible model is that of a series of
> mono IEEE 32 bit floating point data streams running at a fixed
> sample rate. This kind of model is easy to support in an
> environment where all access to the audio interface occurs
> synchronously with the interface's "interrupt" state.
I had already thought a solution for this: to have a PCM variant with
setups specified in configuration and then set at open time.
Then these PCMs has no needs for {hw,sw}_params.
> 2) Establishing connections
>
> How do we get one application to be *able* to talk to another? In
> the current state of affairs, we have a bunch of applications using
> a couple of API's that do not include the idea of sharing data in a
> particularly carefully thought out way (or not at all in the case of
> OSS). They can talk to the hardware with great efficiency, but they
> can't talk to each other.
This is indeed our major problem, but
>
> Kai's site describes the problems with using IPC for the
> interconnection. So we need something else.
the theoretical extra cost is 2*(N-1) context switch (where N is process
count). I'd like to know if indeed this break everything.
That apart I'm strongly convinced that the right architecture need to
handle both cases (one-thread and multiple-process) appropriately.
> Abstraction: alsa-lib already provides a significant level
> of abstraction over real h/w issues, yet
> the typical real-time audio application
> written using alsa-lib is a fairly complex
> affair, with more than a dozen potential
> parameters to be set before starting
> the audio interface, and a multiplicity of
> ways to transfer data to and from it.
About parameters: see above
About multiple ways: this means completeness. And nothing forces a
component to allows all.
> Establishing connections: alsa-lib offers one model for this,
> based on the shared memory IPC mechanisms.
> Such a solution cannot scale to setups with
> lots of clients running at low latencies because
> of the overhead of context switching and the
> associated memory/cache performance loss.
True for context switching, but I don't see the difference concerning
memory/cache. This last thing is related to how a component is written
and not if it run in the same process space or not.
> Temporal sync: alsa-lib offers nothing in this area. ALSA has
> focused all its sync code in the sequencer, which
> is not an audio API (though it would not be impossible
> to modify that). even there, however, the notion
> of time is fairly low resolution, definitely
> not enough to support sample-accurate events.
Here I'd need to understand better what you're asking for.
> Before moving on, I want to stress that I think that alsa-lib is a
> fantastic piece of work. Truly fantastic.
And truly misunderstood, sometimes...
> In particular, alsa-lib does not contain any callback-based model, and
> in the majority of discussions about LAAGA, the notion of the server
> executing a callback for each plugin has been fairly central. This is
> in turn a reflection of the notion that a LAAGA setup is driven
> exclusively by the interrupts from the audio interface - although
> other constraints may exist for certain plugins, they are not
> permitted (in a "legal" LAAGA plugin) to play any role in the
> timing of the execution of the server.
In my mind LAAGA is an audio component API, not an engine...
Then I don't understand how callback absence phrase may be be
appropriate.
The engine invoke component method, that's enough. snd_pcm_mmap_forward
is a callback (i.e. a component method).
> audio applications should be using at all. The LAAGA model as mapped
> out here and on Kai's site is a model of simplicity, and one that has
> worked extremely well in analogous forms for many other
> systems. Notable examples include both xmms and its plugins, and VST
> (FX plugins, instruments), and these days, DirectX for Windows.
If you refer to this names as an example for generic component
reusal/connection, I feel the need to strongly disagree.
> As I have explained above, the current design of alsa-lib doesn't
> contain the elements I think are important for a plugin-oriented
> system. That doesn't mean it can't be changed to include that, but it
> would be a part of alsa-lib that for processing/generating code would
> make the rest of alsa-lib completely irrelevant. such code would never
> use any of the existing API except possibly for some of the transfer
> functions, and probably not even them, since there is a distinct bias
> in plugin systems towards allowing direct memory access to input and
> output buffers (i'm not talking about mmap, just the LADSPA audio port
> idea).
I'm unable to parse this paragraph.
> so, i see a future with two distinct aspects in it. one contains a set
> of applications that continue to expect to control their own audio
> interface. These would include "servers" like a LAAGA, LADPSA or VST
> host, or applications that operate in a non-synchronous way (almost
> all soundfile editors are a good example), do not have particular
> real-time and/or low latency requirements, and/or contain legacy code.
I agree here, but I'd like to precise that the edge is not so static has
it appears. Many applications that "expect to control their own audio
interface" might be moved on the other side.
If a general purpose connection architecture will exists in future, this
will force obsolescence of legacy applications.
> the other consists of plugins much like the ever expanding set of VST
> and DirectX plugins, none of which are concerned with the details of
> audio formats, hardware or software parameters, but just get loaded
> into a server of some kind, process some number of float-based audio
> on a regular basis, and thats about it.
In other words, objects that implement a strict subset of ALSA PCM API
;-)
> i'm not sure that this division is a good thing, and its why Abramo's
> appeal to a single API has some force for me. but i'm also at a loss
> to see how to come up with a single API that can satisfy all the goals
Here I'm sure we have a lot of chances to be successful, but...
> and be seductive enough to convince all/most linux audio developers to
> use it.
... seduction has never been my main strength.
Paul, Kai, I've heard you're "tombeur de femme"... It's something like
that, I suppose... Ok, we may proceed ;-))))
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Fri May 11 2001 - 16:37:00 EEST