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.

Col.

On Fri, Jul 25, 2008 at 08:51:13PM +1000, Peter Dolding wrote:

Now why are not alsa interfaces practical to use. It is ment to be "Advanced Linux Sound Architecture" The complete Architecture. Not something you have to tack bits onto because its not functional or hard to use. Have we got to the point like xlib where the complete alsa-lib has to be reworked for usability.

alsa-lib's weakness from my perspective is the sheer breadth and extent of its API. the simplest polled output case for PCM requires a significant amount of code. there are a dozen snd_pcm_*() functions before snd_pcm_writei() can be called. I can't just open() a device, ioctl() a struct or two to set sampling and buffer parameters, and start write()ing data.

ALSA appears to trade large data structures for large numbers of function calls. I assume this is intended to give finer granularity of error reporting, but it makes programming ALSA very involved, perhaps unnecessarily.

the recent step of deprecating (and subsequently removing) function calls to slim down the API is a step in the right direction.