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

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 

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

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.

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