Subject: Re: [linux-audio-dev] sound API libraries, servers, etc.
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Apr 25 2001 - 00:49:17 EEST
>1. Design overview
> - client applications (ones that produce audio data) are
^^^^^^^^^^^^
or consume
> 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
in my conception, the server makes available functions that the client
can use to read and write audio data to the audio hardware and also to
an internal bus network (so that data can be shared between
plugins). these functions work identically for real physical channels
or the busses.
> - audio data is transfered between server and clients
> using functions calls performed by the server
the word "callback" should probably occur somewhere.
>2. Function callback APIs
>2.1 Client side
> - open/close (initialize/cleanup)
yes.
> - read(int channel_id, ...)
> - write(-- " --)
no :) i think that the server should call
client->process (unsigned long nframes);
and make available:
server->read (int channel_id, ...);
server->write (int channel_id, ...);
> - prepare/start/stop/pause
not sure what these are for. but i'm not against them.
> - set_block_size()
yes.
> - ... probably a few others
haven't needed them yet.
>2.2 Server side (functions passed during client.open(&server_funcs))
> - add_channel
> - remove_channel
> - ...?
in my model, the server controls every physical channel on the audio
interface its using. there is an issue of possibly adding internal
busses, which in aes function identically to physical channels (they
just aren't connected to anything)
>3. Possible problems
> - negotiating the used audio format
we should follow LADSPA and use float everywhere. AES does this
now. clients don't pay any attention whatsoever to the nature of the
underlying h/w interface.
> - we could force all channels to be mono, but it might
> be useful to support interleaved streams
i like mono channels.
> - client-side implementation requires a fair amount of
> work (a helper library for writing client-side
> LAAGA support would help here)
yes, i agree. i still don't have this fully worked out. there are the
same GUI/DSP issues as in LADSPA too. right now, my technique is a
total crock: its the GUI of AES that loads the plugin, whose
initialize() funtion creates both the GTK widgets needed for its GUI
and the AES plugin object, connecting it to the AudioEngine. this
clearly is wrong, and has to change.
>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)
ardour is just another LAAGA plugin.
>- user selects TerminatorX for input and ALSA for output
i doubt that we'd be selecting the output style. its possible i
suppose. and you don't so much select "TerminatorX for input" as "load
TerminatorX" and then "assign TerminatorX outputs to channels N..."
TerminatorX would probably just default to channels 0 and 1.
remember, the idea is that other apps can collect the output of
TerminatorX if it sends data to the internal bus system of LAAGA (and
vice versa).
>- Aes loads the TerminatorX plugin (--> 'client')
>- Aes issues client->open()
> - TerminatorX forks/pthread_creates a new process/thread,
why a new process or 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)
note: in AES the registration doesn't do anything except ensure that
server->write (channel, ...)
will do the correct thing if more than one AES client is writing to
that channel.
>- Aes issues client->prepare()
what's this step for ?
>- TerminatorX starts producing audio data
>- Aes issues client->start()
aes issues client->set_block_size(). after that returns, its assumed
that the client is ready to go.
>- Aes goes into the i/o loop
> - client->read() /* must be non-blocking! */
> - ALSA_dev->write()
not quite how AES works:
alsa_device_io_loop () {
while (1) {
poll (...);
engine->process(nframes);
handle_unused_channels (); /* make sure they're silent */
}
}
in turn, plugins are actually attached to the engine, so we have:
engine_process (nframes) {
foreach plugin {
plugin->process (nframes);
}
}
>Comments?
Love it!
--p
This archive was generated by hypermail 2b28 : Wed May 23 2001 - 20:30:43 EEST