Re: [linux-audio-dev] sound API libraries, servers, etc.

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

Subject: Re: [linux-audio-dev] sound API libraries, servers, etc.
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Apr 25 2001 - 00:35:48 EEST


On Fri, 20 Apr 2001, Paul Davis wrote:

>>Could you provide a url for aes? I'd like to check it out. What's it all about
> there is no URL. currently, the source for 99% of the program is in
> Quasimodo CVS, accessible via the download page at
> http://quasimodo.org/. its the quasimodo/libs/audioengine module.

I think we should definititely at least try the pure plugin based audio
server approach. Like with LADSPA, I think what we need here is a
concrete, short and sweet API proposal (preferably in C).

And it doesn't necessarily need to be very complex...:

--
LAAGA - Linux Audio Application Glue API

1. Design overview - client applications (ones that produce audio data) are compiled as dynamicly loadable plugins (libraries) - server application works by reading audio data from input-plugins and audio hardware (=soundcard), and writing to output-plugins and audio hardware - audio data is transfered between server and clients using functions calls performed by the server 2. Function callback APIs 2.1 Client side - open/close (initialize/cleanup) - read(int channel_id, ...) - write(-- " --) - prepare/start/stop/pause - set_block_size() - ... probably a few others 2.2 Server side (functions passed during client.open(&server_funcs)) - add_channel - remove_channel - ...? 3. Possible problems - negotiating the used audio format - we could force all channels to be mono, but it might be useful to support interleaved streams - client-side implementation requires a fair amount of work (a helper library for writing client-side LAAGA support would help here)

...

If I've understood right, this is very close to Paul's current AES design. To make this a bit more concrete, let's take a practical example:

Using LAAGA for connecting Aes/Ardour (server) and TerminatorX (client):

- TerminatorX is distributed both as a standalone app and compiled as a shared library (LAAGA client) - Aes is started; user starts audio device configuration - Aes shows a list of available LAAGA plugins (and internal services, possibly Ardour itself) - user selects TerminatorX for input and ALSA for output - Aes loads the TerminatorX plugin (--> 'client') - Aes issues client->open() - TerminatorX forks/pthread_creates a new process/thread, which is similar to the standalone TerminatorX - TerminatorX GUI is shown to the user - using the callbacks provided by Aes, TerminatorX register two channels (replacing the normal stereo soundcard output) - Aes issues client->prepare() - TerminatorX starts producing audio data - Aes issues client->start() - Aes goes into the i/o loop - client->read() /* must be non-blocking! */ - ALSA_dev->write() - ... and so on ...

Comments?

-- 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 : Wed Apr 25 2001 - 01:03:16 EEST