Re: RFC: GSound, a GObject library for playing system sounds
- From: Tristan Brindle <tcbrindle gmail com>
- To: Richard Hughes <hughsient gmail com>
- Cc: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: RFC: GSound, a GObject library for playing system sounds
- Date: Fri, 5 Dec 2014 17:33:30 +0800
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]