Re: Replacing Esound with Polypaudio?

[David Schleef <ds schleef org>]

On Thu, Sep 09, 2004 at 12:19:27AM +0200, Lennart Poettering wrote:
> 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.

Ignore this, esound doesn't do it correctly anyway.  Using any
media player with esd successfully seems to mainly be based on
luck.

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

Issues like this are probably negotiable.  There's no decent reason
for an application to need to do this.

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

I don't speak for GNOME, but since I've thought about the problem
repeatedly, I'd be happy to offer ideas.  (I need to either find my
list or recreate it.)

One of my huge annoyances with esound currently is that applications
such as rhythmbox Just Don't Work if you attempt to use GNOME button
sounds while simultaneously playing music.

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

At least from the GNOME side, I assume that most applications
will be either using libgnome (for button sounds) or GStreamer (for
anything more complicated).  PortAudio or SDL supoprt is fine, and
with the esd support, it comes close to the primary goal, which is
to make it highly likely that any application will Just Work with
polypaudio.  IMO, if a user needs to stop the sound server to do
something (like play a movie in xine), they will just not use a
sound server.  The key is to make this highly unlikely.

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

Sure it does.  Just pretend that each release is a new major version,
and change the library name accordingly (e.g., libpolyp-0.4.so.0.0.0,
libpolyp-0.5.so.0.0.0, etc.)



dave...