Ter, 2004-11-23 às 21:33 -0500, Colin Walters escreveu: > On Wed, 2004-11-24 at 13:19 +1100, Jeff Waugh wrote: > > <quote who="Colin Walters"> > > > > > 1) Remove all usage of esound from libgnome and associated applications, > > > and replace it with GStreamer where possible > > > > GStreamer is currently included in the Desktop suite, not the Platform, so > > this would mean either: a) GStreamer should be proposed for the Platform, or > > b) we consider GStreamer an external dependency, outside the scope of GNOME. > > Ok, good point. Let's get input from the GStreamer maintainers here. > What are your plans for 0.9 and GNOME 2.10? Can you make the commitment > to API/ABI stability that the Platform would require? So, in spite of my previous ranting regarding GStreamer API, I'd love to see GStreamer reach API/ABI stability. It would be worthwhile on its own, regardless of libgnome using it or not. If you add to it a simple ding playing API, then we have a killer combination. But can we still replace esound-the-server with polypaudio, and make GStreamer use it? I mean, we still need cross-process audio mixing, right? Another question, would the gnome_sound_play() API still be available? Deprecated or not? I think it's a great API. Simple, and to the point. Normally applications shouldn't need to worry about caching. Let the library do automatic caching, like libglade does for .glade files. Extra points for using shared memory for cross-process caching. ;-) Regards. > > > > 1a) Where not possible (gnome_audio_connection_get), a compile-time > > > option is provided for systems desiring esound compatibility > > > > So, is the proposed "always return -1" change sufficiently unexpected that > > it would have a detrimental affect on semantic API compatibility? If not, > > are there any further reasons to be uncomfortable doing it? > > Note that libgnome already detects esd at configure time, and if it's > not present, gnome_sound_connection_get just returns -1. So we've > already been deferring this decision to GNOME distributors. > > > > 2) Enhance GStreamer to provide a sample ding caching abstraction > > > 3) Drop esound from the official platform; or perhaps "strongly > > > deprecate" > > > > We'd have to deprecate it only. > > Ok. > > > > 4) Make GStreamer the only sound API for GNOME; official > > > Platform/Desktop modules are not allowed to require anything else > > > 5) Give a link in the release notes to Polypaudio and/or esound for > > > systems in need of a sound daemon > > > 6) Participate in dancing in the streets due to demise of esound > > > > This seems like a good enough short term plan, but I'd be surprised if this > > doesn't come up again in the future. :-) > > I'm not sure why it would; once we standardize on GStreamer, Polypaudio > versus ALSA versus Solaris audio versus MAS, etc. is as offtopic here as > Linux versus FreeBSD is. > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature