[alsa-devel] alsa-lib has anyone ever looked at taking it cross platform?

Colin Guthrie gmane at colin.guthr.ie
Fri Jul 25 14:49:20 CEST 2008

Peter Dolding wrote:
> Pulseaudio and all other Sound Servers since its a extra service adds
> a extra point of complete sound failure to the Linux sound stack or
> what ever stack they happen to be operating on top of.   It more of a
> hack around the limitations of the alsa framework.  ALSA was really
> designed to avoid the need of such extras.  The existence of
> Pulseaudio is really sign of failure.  Reason Sound Servers existed at
> first due to the failures of OSS to provide a multi application sound
> support.  ALSA was really designed to do away for the need of sound
> servers completely.  Now alsa is failing to provide per application
> sound control and a sound server is back for another pass.

I really don't see why the existence of sound servers is a failure of 
ALSA. ALSA does it's job very well by providing the necessary hardware 
drivers and an interface to them. The kind of things needed by a modern 
desktop sound system, however, goes way beyond the 1:1 hardware interface.

At the most basic level, sound servers can be reduced to just software 
mixers. The name "sound server" has a very bad reputation that (these 
days) is not deserved. To say that pulseaudio's existence is a failure 
of ALSA is doing ALSA a massive disservice. Sure, the software mixing 
can be done by Alsa's DMIX but DMIX is just a "sound server" anyway, so 
what specifically makes DMIX better or worse than PA in this regard? 
Because DMIX is started automatically? Because it's in kernel space? 
None of these arguments hold up when you get involved at the level of a 
distribution who packages things together correctly.

Pulseaudio is just a name and the kind of things it does are very much 
different to the core goals of ALSA (with the exception of the obvious 
overlap between DMIX and PA). The two fit very well together IMO.

If it makes you feel any better, just call pulseaudio "ALSA Desktop 
Services". Like I say it's only a name!

> Now if you want to keep on thinking along that line has ALSA got to
> the point it should be dumped like OSS has been dumped because of its
> limitations?

Of course ALSA should not be dumped! ALSA does it's job very well, and 
PA does it's very well too. I really don't see how you got to that 
statement from what I said. PA doesn't try and reimplement ALSA, it just 
implements the higher level audio stack.

> alsa-lib to freebsd or somewhere with oss most likely could be done
> really quickly since we already have a oss output option.
> Its also like saying the Linux Standard Base is only used by Linux.
> Its not its also used by a few non Linux's.   Driver section of ALSA
> most likely will always be Linux only.   But the wrapper layer that
> hides the hardware from the software really does not have to stay
> Linux only.  Alsa is going up to be part of the Linux Standard Base
> its about time we all start looking at how it can be made most useful.
>  Provide all the features it should and work for stability.

I've not programmed much with alsa lib but I do know it's not all that 
simple. That's there are several other layers on top that exist. There 
API is complex and powerful but it also open to a lot of abuse. There 
are many ALSA client apps out there that are poorly written. That's 
simply because the API is complex and it is easy to make mistakes that 
do not surface with one setup but do on another. Making apps work nicely 
with DMIX was a pain and as soon as you remove the hardware aspect of 
the underlying system (e.g. to replace it with a plugin like bluez or 
PA) lots of interesting issues come to the fore.

IMO Pulseaudio is the future of the high level audio stack on linux and 
alsa is and will remain to be the future of the driver/low level part of 
that stack. The callback architecture is more suited to modern practices 
which is also adopted in CoreAudio and even on Windows these days. Over 
(a very long period of) time I think we'll see less and less direct 
impelmentations on top of alsa-lib and more on top of PA. That's my 
prediction anyway (and I'm talking about general purpose desktop stuff 
here; specialist sound stuff like Jack will probably still interface 
directly with ALSA).

While porting alsa-lib to other platforms is fine, I don't think it's 
the ideal future scenario.

And to be even clearer than I have been (if possible) I'm not 
badmouthing or insulting ALSA in any way here. I need it and use it and 
rely on it and I don't see that changing!

Just my thoughts.


More information about the Alsa-devel mailing list