15 Jun
2009
15 Jun
'09
12:27 a.m.
On Sun, Jun 14, 2009 at 3:51 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
AFAICS, Alsa has shot itself in the foot by trying to
provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
lets be fair to ALSA. this design is a result of pressure from actual
app developers. i think you sometimes forget that the world of audio
programming extends way, way outside people who want the kinds of
things that we tend to want. take a look at phonon (from KDE) - this
is a living, breathing definition of the kind of thing that
non-pro-audio, non-music-creation, non-sound-installation audio app
developers imagine they want. but ALSA tries to give this same general
idea to them in a rather interesting way: your code doesn't vary when
you use a device that can support your data streams natively (in
hardware) versus when you use one that requires some extra conversion.
open "hw:0" and then do FOO. alternatively, open "plughw:0" and then
do FOO, regardless of the capabilities of the underlying hardware. FOO
remains constant. No "if (hw->can_support (sample_rate)) { ... }"
conditionals etc etc.
this was no small accomplishment, even if for the subset of the audio
programming world that we tend to inhabit, its largely irrelevant. the
idea that you can write a single chunk of audio io code, and
regardless of the capabilities of the underlying hardware, it will
just work - this was really quite a large goal for ALSA. maybe it
would have been preferable to have started with something more like
gstreamer - this behaves in a way similar to the broad goals that you
are describing, even if its API has some baroque complications. but i
think the vision/gaze/focus was just on a different model - open the
real hw, use it as-is, or open up a virtual device and have things
"just work".
where things maybe went wrong was the idea of defining a lot of
different *kinds* of virtual devices via a config file, including ones
that did multi-app multiplexing, device sharing, even i/o to
non-hardware devices like the ALSA JACK plugin.
now compare the situation with CoreAudio (i know, i know: i sound like
a broken record). there is only 1 sample format when interacting with
an audio interface. but there are lots of appallingly designed APIs
for stream conversion before you hit the "hardware". moreover the
device you open will do multiplexing to the real hardware *AND* sample
rate conversion automagically. yet - this whole system can be
reasonably easily made to reroute any applications audio via a
user-space system like JACK without the app even knowing anything
about it. there is also an "aggregate device" system similar to ALSA's
"multi" plugin, and which works even worse (or at least, in a way that
puts some absurd requirements on an app developer - oops, all playback
channels from your device just vanished). the similarities and
differences with ALSA are remarkable.
If such a library had been created by the ALSA devs
instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
i don't think this is accurate. esd and artsd predated ALSA. when we
started work on JACK, nobody really knew how it should work (in terms
of implementation or API or general design). what does seem sad in
retrospect was that when we started JACK we did so in a context that
was deliberately "non ALSA". this had had costs - JACK lives outside
ALSA - but also benefits - JACK runs on all 3 major contemporary
operating systems. the goals for JACK at that time seemed like
something that was outside the scope of what ALSA was attempting to
accomplish, but in hindsight, it all seems very much part of the same
goal(s).