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

[Bastien Nocera <hadess hadess net>]

On Fri, 2014-12-05 at 17:33 +0800, Tristan Brindle 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. 

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.