Re: pulseaudio vs gnome

[Alex Jones <alex weej com>]

I think that bells and whistles belong in a model similar to Freedesktop
Notifications, but all other multimedia functionality should be done
with GStreamer directly.

On Sun, 2007-01-21 at 00:17 +0200, Marc-André Lureau wrote:
> 
> 
> On 1/20/07, Ronald S. Bultje <rbultje ronald bitfreak net> wrote:
>         On Sat, 2007-01-20, Damon chaplin wrote:
>         > Before it goes in I'd like to see a clear roadmap for audio
>         in GNOME,
>         > with support for things from simple beeps up to pro-audio
>         apps.
>         >
>         > I guess this means gstreamer, PulseAudio and JACK. Is that
>         the plan?
> 
> 
>         esd is in the platform because it already is. Realistically,
>         it doesn't 
>         belong here. Any replacement technology _to have complete
>         feature
>         equiality with esd_ should be completely optional and a user
>         should be
> 
> I started to write the l.g.o/PulseAudio page just to track the
> progress and see who is interested to make this happen. Now, its
> getting interesting and hopefully good thing will happen soon. 
> 
> I agree with what Ronald wrote. Those are technologies that should not
> be *part of* GNOME. And unfortunately, the dependency GNOME have on
> esd (which is not really that important btw) is due to the broken API
> of libgnome. Straight to the point, that is clear that no application
> should use directly PulseAudio/Jack if they want to be *GNOME
> compliant* (even if I don't really know what *compliant* mean :). 
> 
> But note that PulseAudio is a bit more than a esd replacement. And we
> probably have to think how we will provide/export its goodness &
> internal state/parameters/configuration to GNOME. Just take a look at
> all the cool apps that comes with PulseAudio. Of course, they are a
> bit complicated, but we can write a simplified preference applet. That
> makes me slightly think that PulseAudio *might* be part of GNOME
> anyway, but this should be discussed in the future. Make the sound
> server choosable/transparent is enough for now. 
> 
>         That probably means something like GStreamer to make it
>         bearable for
>         applications that really don't care and just want to play
>         song.mp3 or
>         beeps. And that should suffice.
> 
> This remark pops up an interesting question: do we really want gnome
> apps linked to GStreamer to play "bling"? Furthermore, is GStreamer
> API suitable for a simple desktop applications (nautilus, mozilla,
> notify, bling API...) ? I have posted a proposal to define an API for
> desktop sound on freedesktop/dapi/gnome-media mailing lists (without
> much success) - but once again, we don't care about implementation at
> this stage (wether it uses a daemon or not, if it use GStreamer or
> Pulse or anything else). I really think we need to discuss such idea
> to replace the libgnome sound API. Of course, it would be good to have
> people from GStreamer/DBus/PulseAudio discuss such idea also. 
>  
> If you look at the code that use esd directly, its only because
> libgnome doesn't provide a simple/complete sound API. And now its time
> to fix libgnome sound to get rid of esd.  At the same time, lets bring
> some new cool things like theming/positionning/introspection &
> control... But that is probably not the good place to discuss this in
> detail. 
> 
> After FOMS and DAM3, one has said that new mailing lists will be
> created to discuss desktop audio API. I would like to define also a
> *sound desktop* API. Where are those mailing lists? anyone?
> enough for now,
> 
> best regards,
> 
> -- 
> Marc-André Lureau, GSmartMix 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list