Re: Polypaudio for Gnome 2.10, the next steps

[Colin Walters <walters redhat com>]

On Tue, 2004-11-23 at 17:32 +0100, Lennart Poettering wrote:

> Besides, Polypaudio already exists and works, while your ALSA pulgin
> doesn't exist yet.

For the local case, asym does exist.

> BTW: I investigated to write an ALSA plugin for passing audio data to
> polypaudio. Unfortunately the internal ALSA library API isn't flexible
> enough for allowing such things without major changes (i.e. while the
> external ALSA API exports multiple audio file descriptors for the
> application to select() on, you don't have the ability to export more
> than one fd from a single plugin. In addition to that there's no way
> to change during runtime what to select() on: for readability,
> writability or both). 

That's useful to know.  Probably should file an ALSA bugreport.

> I personally think the ALSA API is ugly, much to complicated and way
> over-engineered.

The thing is though, the ALSA API has to be at a very low level so that
people who want to can get the most out of their card's hardware.  The
fundamental point in this discussion that Seth raised is that if we
explicitly require Polypaudio in order for local sound mixing to work,
then Polypaudio has to become *the* sound API.  If Polypaudio doesn't
support accessing some card feature or whatever, then application
developers have to make a choice between sound mixing and card feature,
which is broken.

For Fedora, we've put in a lot of work in switching lots of various
applications to Alsa; as the maintainer of most of Fedora's desktop
multimedia stuff, I am not looking forward to switching *again* to
something different.

Anyways, this discussion between ALSA versus Polypaudio is mostly
irrelevant (on this list) if GNOME switches to using GStreamer
exclusively.  What I'm arguing against is Polypaudio becoming the
required sound API.  If distributors want to use Polypaudio below
GStreamer, more power to them.  But GNOME shouldn't be dictating it.

> Another thing that I miss in your design: sample caching. That's
> really something you want to have (in a networked scenario) when your
> desktop generates those "ding" sounds whenever you press a button.

Sure; but this should be implementable.

> There are at least five important areas where polypaudio is strong in,
> and where it supersedes most other implementations I know:
> 
> - Networked sound. I do believe that this a very important issue. 

Sure; but this is mostly an issue *below* the sound API layer.  

> - Concurrent playback. You can achieve this with ALSA dmix. However,
>   the last time I checked, it was incompatible
>   like hell and failed to work in more places than it did work in
>   other places. 

Just bugs, should be fixable.

> - Portability and compatibility. Polypaudio is (probably) much more
>   portable than ALSA. 

But this is not important to GNOME, because we should be using GStreamer
exclusively.

> - Polypaudio is actively maintained and has a maintainer who's really
>   interested in getting polypaudio into gnome. ;-)

You should instead argue to distributors individually that they should
use Polypaudio instead of ALSA/(whatever the Solaris sound API
is)/esound, etc.  GNOME should be agnostic.