Re: [linux-audio-dev] LAAGA - how are we doing ?

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

Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Sun May 06 2001 - 15:14:52 EEST


On Sun, 6 May 2001, Jim Peters wrote:

>> In my desing, it's up to the server to care about which buffers are
>> assigned to plugins, whether multiple plugins are assigned to same
>> channels, whether input and output buffers are physically the same
> Yes, all of this is fine, but it doesn't address the question of how
> things get connected together. A plugin loads itself up and says to
> the server "Give me 5 channels", and gets five handles back (or
> whatever), and starts writing to these - but what then ? How does
> something connect to these channels to record this output ?

It doesn't and it shouldn't. :) Just like with LADSPA, LAAGA plugin
"announces" certain amount of audio input and output ports. LAAGA server
can then provide the user with a list of available plugins and their
ports.

> Can you talk me through a concrete example, as you see it ? Let's say
> we have a MIDI synth engine that we want to record using `ardour'.
> How do we get these two to talk to one another ?

Ok, let's see. I replace ardour with ecasound to make the explanation
shorter:

ecasound -a:bus1,bus2 -i laaga,xxx_midi_synth \
         -a:bus1 -o msynthoutput.wav \
         -a:bus2 -o alsa,my_soundblaster

... when ecasound connects the above setup, the xxx_midi_synth is
instantiated. In the plugin->init(), xxx_midi_synth's GUI is created. All
plugin output ports are assigned to ecasound channels 0...n. During
processing ecasound will duplicate all bus1 channels by copying them to
bus2. This allows you to hear what you are playing.

Now the point is that the above design is very different from for instance
Ardour's bus-concept. But the LAAGA API should handle both cases. It
doesn't make sense to demand that all LAAGA servers must use
ardour's/gstreamer's/arts'/ecasond's internal signalflow structure.

> I quite understand your wish to not get into a flow graph kind of
> model, and keep the focus on interconnecting applications, but we have
> to choose some model of how to manage the user-side view of how things
> get connected because this impacts on the server and API design.

It's true that all servers must provide a solution to this, but doesn't
affect the LAAGA API.

-- 
 http://www.eca.cx
 Audio software for Linux!


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

This archive was generated by hypermail 2b28 : Sun May 06 2001 - 14:49:34 EEST