On Fri, 2014-12-05 at 17:33 +0800, Tristan Brindle wrote: > > On 5 Dec 2014, at 1:42 pm, Tristan Brindle <[email protected]> wrote: > > > > It looks like the Windows equivalent is the PlaySound() function[0]. > > > > So I guess there are a couple of possible approaches if we don’t want > > GSound to stay as a separate library: > > Having given it a bit more thought, there is a potential (possibly crazy) > third option: > > > 3) Add the GSound API to GIO as an extension point, but implement it > directly using GStreamer, and don’t use libcanberra at all. > > > > The reasoning is this: > > * libcanberra is a large, complex low-level library (it doesn’t even > use GLib, presumably to make it more palatable to the KDE folks), and > appears to be unmaintained now that Lennart has moved on to other > things.
It's not that large or complex for what it does. It also talks to PulseAudio directly, including handling sound effects caching. And if there are any long-standing bugs that need handling, there are certainly others that can look into it. > * Richard talked about the “platform story”: well, GStreamer *is* our > platform media framework, as QuickTime is on the Mac. And just as > NSSound uses QuickTime under the covers, it would seem natural for us > to use GStreamer. And libcanberra can use GStreamer. Using GStreamer directly is a good way to throw away the benefits of using libcanberra (who's going to mlock() the necessary bits so MP3 ringtones don't take ages to start?) > * A direct implementation of GSound in GStreamer would seem relatively > easy: resolve the event id to a sound file (could borrow the Canberra > code to do this), then pass the filename to a GStreamer playbin. And reimplement the sound theming code in libcanberra? > If the audio sink is pulsesink, then inject other attributes into the > pipeline to keep things like the positional audio working (if it works > now? I’ve never actually noticed it). Yes, look at the speaker test code in the Sound settings. > GStreamer would take care of all the threading and locking etc that > libcanberra currently has to do. > > * The GStreamer implementation could be used on Windows and Mac > (presumably as a compile-time option), until someone contributes, say, > a Mac implementation of the extension point which uses NSSound or > QuickTime instead. > > * It’s actually one less library to worry about (since we can assume > GStreamer always will be available on Linux). > > * Effectively, this would turn GSound into an independent > reimplementation of the Freedesktop sound spec living in GIO, rather > than a GObject-y wrapper around the reference implementation living in > its own library. There would seem to be precedent for that. > > > Any thoughts? Does this make sense, or have I gone off the deep end? The latter I'm afraid. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
