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

[Arun Raghavan <arun accosted net>]

On 5 December 2014 at 15:03, Tristan Brindle <tcbrindle gmail com> wrote:
> > 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?

Any updates on what's being planned here?

Cheers,
Arun