Subject: Re: [linux-audio-dev] LAAGA - key issues
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Sun Apr 29 2001 - 23:34:44 EEST
On Sat, 28 Apr 2001, Jim Peters wrote:
>> * LAAGA should provide full synchronation (all apps are always
>> in perfect sync + means for issuing start/stop/etc commands).
> going to be a problem. Really, if an external process (application,
> whatever) needs to be synchronised with the hardware, it should
> provide a plugin, and instruct the audio server to load that plugin.
> In that way the application is split into a non-critical part (its
> main process) and a critical part (the plugin loaded into the audio
> server). This means that it is not necessary for the audio server to
> be synchronised with anything except the hardware.
Yes, definitely. By synchronation I was referring to starting/stopping the
audio server operation (ie. when plugin callbacks start to get
called). In every audio applicaiton, there is a section where:
1. audio device is prepared
2. if device is opened for output, data is written (prefill)
3. device is started
4. application writes/reads to/from the device at a (hopefully)
constant rate (using poll/blocking_read/_write for timing)
5. device is stopped
This is not always explicit, as both OSS and ALSA offer the start_on_data
feature. From LAAGA's point of view, when someone (server or possibly some
client) issues start/stop, the audio server will start/stop. And of
course, when server stops, client callback won't be called anymore.
>> * Should it be possible to be able to make LAAGA connections
>> between already running apps? The other alternative is
>> that clients are compiled as plugins and instantiated
>> by the server.
>> * Should it be possible to add and remove clients when the
>> server is running?
> Yes to both, I think. I would suggest that both alternatives for
> point one be used together.
That's what I was afraid of. ;) Seriously, I think first we should
concentrate on the static case where server instantiates the plugins, and
during processing nothing else happens but audio i/o. But of course, the
dynamic aspect still have to be kept in mind all the time.
I think the Evo project has some very useful code for these purposes. It
basicly had a system for assigning sampler voices dynamically to the rt
audio thread. Also, for connecting independent processes, there's lot of
ready solutions available (aRts, esound, aserver, nas, etc, etc).
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Mon Apr 30 2001 - 01:01:40 EEST