Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_op.net)
Date: Wed May 09 2001 - 02:00:28 EEST
>I agree, although I'm still a bit lost ;)
you have my sympathies. honest.
>To start things off, might I suggest a specific realworld example to
>be demonstrated for each proposal? I'm thinking that of a typical
>(3d) game. You have it loading the samples of various rates, applying
>various distance and direction effects to them, mixing them together,
>and outputing them. The output could go to various things - a
>soundcard, the harddisk, the network for remote use, or even several
>things at once. And in the case of the soundcard, there may be two
>apps outputting sound at once (requiring mixing).
1) the LAAGA proposal originated by Kai, somewhat rooted in my AES
system, is not concerned with hard disk output or input. there
are no channels connected to disk streams, primarily (IMHO) because
there are too many design decisions to be made in how this is done,
and no single set of those decisions will work for all
clients/plugins. Hence, disk i/o is the responsibility of the
client/plugin.
2) there is no mixing other than simple unity-gain combination of
signals. each client/plugin of the LAAGA server is responsible for
controlling its own gain levels.
>And while I'm at it, why don't I give my own ideas on how things
>should be organized? I would split the components into two types -
>symmetric and asymmetric. Symmetric components take a given amount of
>input from the engine, and return an identical amount of data to it
>(probably using the same buffer). Asymmetric (not surprisingly) do
>the opposite, take a given amount of input from the engine (possibly
>none), and a different amount of data. This could be from changing
>the rate for the sample, reading in from a microphone, or outputting
>to the soundcard.
this is impossible. if the engine says "process (64)", then you must
generate and/or process 64 frames. you can generate those frames from
less or more than 64 frames of "source data" (e.g. by interpolation or
data reduction), but you have to still come up with 64 frames or
you'll be responsible for audio artifacts.
>Another distinction that could be made is internal vs external. The
>game may be able to do all it's internal mixing and sound effects in a
>single thread, but once it outputs it (to the soundcard or wherever),
>another process would have to handle it. Unless of course it's
>outputting directly to the card, then there's just the kernel-level
>hardware api.
As mentioned above, in the LAAGA proposal, there is no external mixing
built into the API. Of course, you could choose to send all your
output to 1 or more channel corresponding to a set of internal busses,
and then use a second client/plugin that reads/writes from those
busses, provides gain control, and then forwards the result to a
physical channel. but this is merely enabled by the API, its not part
of it.
the client/plugin (unless it specifically investigates) has no clue
what a given channel is connected to. whether a channel is an internal
bus or is connected to a h/w interface is invisible when using the
functions designed to deliver data to the engine. no client/plugin has
any (visible) access to the audio h/w. all it can do is call
read_from_channel() and write_to_channel().
to reiterate, all LAAGA offers is:
* abstraction of the audio h/w into a series of mono, 32 bit float
channels along with functions to write/read data to/from them.
* totally synchronous execution of all clients/plugins; each plugin
has its "process()" function called by the engine at the right
time.
* data sharing via internal busses accessed via the exact same
mechanism as physical channels.
nothing (or almost nothing) more.
does that make it any clearer?
--p
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 03:20:40 EEST