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 <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
