Re: Replacing Esound with Polypaudio?

[Lennart Poettering <mztabzr 0pointer de>]

On Wed, 08.09.04 14:55, David Schleef (ds schleef org) wrote:

> Although this has not been discussed formally, one of the likely
> requirements of an esound replacement is drop-in compatibility.
> This compatibilty can either be at the libesd ABI level (i.e.,
> provide a library called libesd with the exact same ABI that
> accesses the polypaudio server) or the line protocol level (provide
> a daemon that talks the esd protocol.)  It appears you've done
> the latter -- I'd like to hear feedback from users as to how well
> this works.  

This works quite well. The only program that breaks I know is the old
"vumeter" from gnome-media. This probably due to the fact that
vumeter is totally broken. It segfaults after some time running.

But anyway, I am not a "user",  so please ignore my opinion on this.

The only real big issue with esound compatibility is latency
behaviour. Esound has a totally stupid API for this. I am unable to
reimplement this sanely so that client applications get sensible
latency values from libesd. That means using mplayer over esd on
polypaudio won't make you happy.

> Ideally, as part of a transition, you'd provide the libesd
> replacement as well.

This is probably not as easy as its sounds: libesd exposes the
connections's file descriptor to the client application for direct
access with write(). There is no sane way I can emulate this, since
polypaudio speaks a much more complicated protocol on the line. The
only solution I see here is giving out a socketpair() fd here and
having a background thread that transmits all data to the polypaudio
server. But that's ugly, especially for latency.

> Of course, an esound replacement is just the beginning.  Esound has
> numerous deficiencies, including a poor line protocol, terrible
> API, limited to 2 channels, poor mixing control, etc.  Personally,
> I attempt to ignore everything esound does when thinking about
> a sound server.

The issues you describe here are all solved in polypaudio, except one:
currently you can specify a single volume value for each sink. It is
applied to all audio channels equally. I am planning to add support
for per-channel volumes in the next time.

Please elaborate on the exact features you'd require for a new sound
server for Gnome. I need to know them so that I can implement them.

> GNOME and KDE (not surprisingly) have very similar requirements for
> a next-generation sound server.  One is that it needs to have a
> decent API that is absolutely going to be stable over the course
> of KDE-4 and GNOME-3.  This probably means several revs of the API
> before stabilizing to weed out any problems.  Another is that it
> needs to be ported (not just portable) to a bunch of platforms.
> Also, sound server projects fail because nobody wants to do the
> work to port applications to a new API -- having at least a few
> developers who spend time porting applications would be really
> helpful.

I doubt that it is a good idea to port all currently available
programs to polypaudio. I'd prefer if the people would go with a sound
abstraction layer such as PortAudio which seems to be the most mature
API right now. A driver for PortAudio is the next big thing on my todo
list. (As soon as it gets into Debian)

You're right, polypaudio currently works on a single platform only:
Linux. Anonyone interested in doing more ports?

> Many GNOME and KDE people would like to see a common sound server.
> Based on what I've seen, polypaudio appears to be a front runner.
> You might want to start working with the freedesktop people to get
> a little more exposure, since Polypaudio doesn't seem to have much
> traction in the community yet (no Debian package and no GStreamer
> plugin, for example).

That's a good idea, I'll do that.

Sine the soname isn't fixed yet I would not make much sense to have a
package in Debian.

Right at the moment I am working on a polypaudio sink for gstreamer.

Lennart

-- 
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }  
www { http://0pointer.de/lennart/ } icq# { 11060553 }