Subject: RE: [linux-audio-dev] Still I cannot understand why...
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Sat Dec 15 2001 - 17:41:41 EET
On Fri, 14 Dec 2001, Ivica Bukvic wrote:
> My thought is to develop a sound daemon that would be compatible with
> older apps using esd and artsd, based on alsa-server, with the
> efficiency of jack, and ability to share audio resource(s) with the
[...]
> A joint effort would make this not only doable but relatively quickly
> achievable. Imagine just how much time does each programmer waste on
> implementing their own version of efficient sound signal pooling process
> within their own application. Now multiply that by the number of linux
I'm afraid it is not all that clear that the sound daemon you
describe is doable, let alone relatively quickly achievable.
Few points I'd like mention:
1) Majority of current audio apps aren't realtime-safe
You just can't plug these apps to an audio framework that is run with
lowlatency parameters. And it's not possible to fix application problems
on the server side.
So we can either rewrite all audio apps or emulate the OSS-API.
Unfortunately only rewriting fixes the lowlatency-related problems.
Emulation can work, but _not_ with lowlatency parameters.
2) Combining JACK and ALSA?
At least in theory it is possible to write an JACK ALSA plugin. It
would be very tricky to combine the ALSA PCM and JACK APIs, but I think it
might work. So 'jack_process(frames,buf)' would be replaced by a
combination of ALSA poll() and snd_pcm_read/write (or mmap commit).
Paul has mentioned the callback-driven design as the cornerstone of JACK,
but I think synchronous execution of clients is really _the_ key feature.
Of course, a callback API is more natural way to achieve it, but the
wait()-then-operate() approach works, too.
As ALSA has an OSS-emulation layer, this would mean that all ALSA and OSS
apps would be able to communicate with the JACK framework. But we still
have the problem of badly behaving apps. You could use them with jackd,
but after a couple of seconds you'd get an xrun and jackd would drop your
app out from the active clients list. Not an optimal solution..
But for apps that have realtime-safe audio operation, this ALSA JACK
plugin would be the simplest way for JACK connectivity.
3) A lowpriority frontend server? aRts and JACK?
The only reasonable solution I can think of is adding a new audio server
to the framework, which would multiplex (possibly badly behaving) OSS
audio streams to the JACK server. The frontend server would have to use
large per-client buffers, so you'll lose low latency, but you could still
use your old OSS apps without shutting down JACK. For apps like desktop
sounds, mp3&ogg players, etc, this solution would be sufficient.
4) The big API debate...
The real _BIG_ question is what audio API should Linux applications use.
This is a difficult one to say the least. First of all this divides our
little community to pieces. Paul offers the JACK client API, ALSA people
want us to use the ALSA PCM API, KDE&GNOME people advocate CSL (Common
Sound Layer), Gstreamer folks might prefer people to write Gstreamer
components, etc, etc ... These are of course just my assumptions, so I
apologize beforehand if I've misunderstood people.
Anyway, at the same time, _majority_ of both audio app developers and
users are not part of these groups, and just know about the kernel API,
and that's OSS. Even if ALSA gets integrated to linux-2.5.x, the OSS API
is still there.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Sat Dec 15 2001 - 17:37:39 EET