Re: RFC: GSound, a GObject library for playing system sounds

[Tristan Brindle <tcbrindle gmail com>]

> On 5 Dec 2014, at 1:42 pm, Tristan Brindle <t c brindle gmail com> 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. 

* 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.

* 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. 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). 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?


Tristan