Subject: Re: [alsa-devel] Re: [linux-audio-dev] Re: Toward a modularization of audio component
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Fri May 04 2001 - 23:24:12 EEST
On Fri, 4 May 2001, Abramo Bagnara wrote:
> The point is that I don't want *another* API, I think that to have *only
> one* API is the true strength of the proposal.
[...]
> LAAGA on LADSPA on CSL on ARTS on OSS? No thanks. (the example is
> arbitrary)
Ok, I'd like to slow things down a bit. If we look at the current linux
audio scene, we'll notice that:
- currently only few apps even support >16bit and >2ch audio
- even if we forget performance and low-latency for a moment,
connecting audio apps to each other is far from common in
linux audio (even though frameworks like aRts and aserver are
available)
- we don't have a standard API for accessing sound hardware
(standard = used by most audio apps); on the contrary most
popular audio apps have support for multiple different APIs
So there's plenty of work even in the ridicilously-high-latency,
nano-bandwidth audio world. :) And one point to remember is that _we
always need an API to access the audio hardware_. Without ALSA and OSS
LAAGA wouldn't be of much use.
As for LAAGA, I like to view it as a "monolithic audio app" design, where
the main app is build from independent audio consumer and producer
components. The only catch is that our main app (the LAAGA server) must
follow the single-thread audio engine design. Now it might be that this is
not the only way to write efficient audio applications, but still, this
design seems to work in practise:
ardour:
- streaming 24ch, 32bit, 48kHz audio (~5MB/s!) without
dropouts _and_ with-low latency
EVO:
- a realtime, low-latency MIDI-sampler that can
stream large samples from _disk_
ecasound:
- dropout-free audio playback with system load over 3.00
(smp-machine, load caused by simultanious /proc, disk
and cpu stress tests)
- under identical situation, enabling the "traditional"
operation mode leads to audible pauses exceeding
700ms (!)
... and there are many more examples. Now I don't know, maybe the above
examples are just lucky coincidents, but it's a fact that these results
are real, and at the same time they were not trivial to achieve.
Would it be possible to to use multiple individual apps (= multiple GUIs),
together and still take advantage of the single-audio-server approach? Now
that's what LAAGA is all about. It clearly is not meant to be a new
general API for writing audio apps. At least now, the actual APIs are not
the main interest. It's the basic concepts that should be discussed...
Whether there will ever be real LAAGA client apps is still uncertain to
me. It might turn out that it's easier to write custom servers
(Ardour/Aes+Quasimodo, aRts/Noatun+Khdrec, gstreamer/sinks,
ecasound/audioplugins), which again use the ALSA/OSS APIs...
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Fri May 04 2001 - 23:18:14 EEST