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

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 

* It’s actually one less library to worry about (since we can assume GStreamer always will be available on 

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]