Re: Proposal: replacing esound with polypaudio in 2.10

[Christian Fredrik Kalager Schaller <uraeus gnome org>]

On Fri, 2004-10-29 at 14:55 +0200, Lennart Poettering wrote:
> On Fri, 29.10.04 12:17, Christian Fredrik Kalager Schaller (uraeus linuxrising org) wrote:
> 
> > Well they have already accepted glib through the accessibility stuff,
> > and if they go with GStreamer as their default then glib usage for
> > polypaudio should be no problem at all. And I honestly believe that
> > unless they go for GStreamer as their default media backend there is no
> > chance they will choose polypadio as default sound server.
> 
> Anyway I am not going to port polypaudio to glib now.

No problem for me :)


> > > For resampling polypaudio relies on libsamplerate (aka "Secret Rabbit
> > > Code"), which contains a few different interpolators.
> > David Schleef is looking into pulling the samplerate code out of
> > GStreamer and into a separate standalone library. It will be LGPL
> > (opposed to libsamplerate which is GPL) and technically it should be 
> > at least just as good. So it hope that when the time comes you consider
> > switching.
> 
> Is there a need for having both libsamplerate and a new library
> around? What is the advantage of gestreamer's resampling code over
> that of libsamplerate?
Ronald partly answered it. In addition I have heard a complaints about the quality of resamples
API, but I have no personal experience on that, just parroting others.

> What I'd really like to see a libmix for mixing audio.
> 
> > Jeff also mentioned moving libgnome over to libpolypaudio instead of
> > libesound. I think we should move libgnome over to GStreamer in a
> > similar fashion to what Jorn made patches for a long time ago. That way
> > if people choose to not go with our default (polypaudio) but instead
> > output directly to the soundcard for instance then all of standard GNOME
> > follows this instead of most apps switching yet some things like 'dings'
> > not switching. This also solves the issue of polypaudio not being ported
> > everywhere yet as platforms which polypaudio still do not support can
> > keep on using esound for instance, so it makes the transition period
> > easier.
> 
> You would lose sample caching which both esound and polypaudio support
> that way. Or does GStreamer contain an abstraction for cample caching?

The caching of ding sounds come up every time the issue of sound servers
are discussed :) If it is truly important I think adding support in
GStreamer for abstracting it is the way to go yes. 

Christian