Re: Proposal: replacing esound with polypaudio in 2.10

[Christian Fredrik Kalager Schaller <uraeus linuxrising org>]

On Fri, 2004-10-29 at 01:02 +0200, Lennart Poettering wrote:
> On Thu, 28.10.04 21:26, Alan Cox (alan lxorguk ukuu org uk) wrote:
<SNIP>
> > > > It's not compatible with KDE while moving to arts would be.
> > > Come on. Arts is dead.
Agreed, KDE can't wait to drop arts (and artsd I guess) fast enough so
arts is not a solution in any way or fashion :)

> > Where do KDE plan to go - to polypaudio - one audio for both would be a
> > godsend.. 
> 
> I proposed adoption of polypaudio to the KDE people on the respective
> mailing list, but they seem to be a little uncertain what to do. Some
> believe that gstreamer would solve their needs for a sound server,
> others that NMM or MAS would be solution. I personally don't consider
> gstreamer being a "sound server", so the discussion was very
> unconclusive.

In the sense they felt GStreamer solved their need for a sound server it
was not because they believed GStreamer to be a sound server. It was
because using GStreamer they make sound server interchangeable in the
sense that GStreamer can output to a lot of different sound servers.

After having made the same argument in regards to GNOME way back and
gotten beaten in the head over the fallacy of the idea that options can
replace making choices, by Havoc and Jeff if I remember correctly, I
tried hard to convince the KDE multimedia people that the policy is not
a good one when we discussed stuff in at the KDE conference in
Stuttgart. I only partially succeeded/failed in the sense that their
current strategy is making even the media framework user chooseable/
interchangeable, but it look like they will choose a recommended
default. I think that default will be GStreamer, although I guess it is
not fully decided yet. 

If they choose GStreamer as their default I guess there is also a chance
they decide to make outputing to polypaudio through GStreamer be their
default.


> In case the Gnome projects decides to adopt Polypaudio I would be in a much
> stronger position for convining them to adopt it as well. ;-)
>  
<SNIP>
> 
> I didn't make use of glib for polypaudio because I want both KDE and
> Gnome to adopt polypaudio. As you probably know the KDE people don't
> like glib very much.
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.


<SNIP>
> > > In the same way you can replace the current, basic mixing
> > > implementation of polypaudio. So, what's your point?
> > 
> > That would be a good idea if people decide polypaudio is the way to go
> > and would fix a lot of the other technical issues about the audio
> > mixing. (and fair is fair audio mixing, volume and rate adaption are
> > not trivial, they just look it which is why esd rate adaption sounds
> > like singing down a drainpipe)
> 
> 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.

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.

Christian