[LAU] Daemons, daemons...kill those daemons.

[Fernando Lopez-Lezcano]

On Sun, 2009-06-14 at 22:27 -0400, Paul Davis wrote:
> On Sun, Jun 14, 2009 at 3:51 PM, Fons Adriaensen<fons at 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.

I understand that it was a huge leap at the time but......

I don't know nothing, and most probably things have changed a LOT since
then, but when I actually tried to write an alsa backend for snd a long
long time ago I failed[*]. You could either use the hw interface,
connect to the sound card directly and then deal with _everything_ in
your program, or you could use the plug interface and get the advantage
of automatic conversions, etc, etc, but then you would be _completely_
isolated from the hardware, you could _not_, for example, find out how
many _real_ channels the hardware behind the plug interface had (to
actually record from them!). It was impossible, you could not even find
which "hw" was behind "plughw" (everything could be potentially
reconfigured though confi files so your guess could be wrong, or at
least I convinced myself of that at the time). If you used plughw, ALSA
would happily tell you that it could record from something like 4
billion channels (or some other equally ridiculous number). This was not
"logically" wrong (and I remember arguing about this), but it was worse
than useless. 

For me there was a disconnect between the needs of a programmer writing
a real app and what ALSA provided. 

[*] to to take advantage of what alsalib supposedly could do :-)

> 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".

In a real program that could record that was, I believe, impossible. Now
if you are talking about a simple program that would, say, play a
soundfile, then yes, of course it worked. 

> 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.

Oh yeah. I never could really find out or understand how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)

-- Fernando


> 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).