Re: pulseaudio vs gnome





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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]