Re: System event sounds / audio feedback



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bastien Nocera wrote:
> See also:
> http://bugzilla.gnome.org/show_bug.cgi?id=368304

Thanks! That's a great pointer. :)

> This needs application support, and widget support. I think you're going
> overboard with your examples though. I think you should file bugs
> against specific applications that you'd want to support specific
> sounds.
> 
> Implementing those with the gnome_sound_ API (or the esd API) would be
> alright as a stop-gap.

The examples were simply things that _should_ be possible, IMHO.
Naturally, they will require application support.

Using the gnome_sound_ or ESounD API really doesn't sound like a good
idea. The audio feedback features in general are not that urgent; the
impression I have is that most people discussing it have it on their
"nice to have"-list (including me). So pushing a quick stop-gap solution
is not necessary.

> That's because we never had a whole slew of potential replacements. The
> current gnome-audio sounds suck (no offense to the original author),
> they sound dated, and badly finished. Compare this to the MacOS (even
> prior to OSX) or SGI sounds.

True, there are not many. I know only of gnome-audio, Fedora's, Ubuntu's
and less than a handful at gnome-look. I'm hoping PulseAudio will spur
some creativity, or this is a chicken-egg problem. :)

Ubuntu's package also conflicts with gnome-audio, so it's already
impossible to install them both simultaneously through apt.

> You can if you use PulseAudio. It's just only accessible with
> pavucontrol, not gnome-volume-control.

Of course, but there should really be a volume slider in the sound
preferences.

>> 1) A replacement for the libgnome could be a GTK+ module, that simply
>> hooks signals and plays sounds. Sounds are preloaded by settings-daemon;
>> no difference from the current situation there.

That's some great info from that bug. But how much sound handling should
belong in GTK+? My concern was about introducing a sound library
dependency in GTK+ itself. I'm also not familiar enough with GTK+
internals and philosophy to write up a proposal right now.

> This sounds like overkill to me, compared to other system sound APIs
> available.

Which other APIs? Looking at the link provided in the bug about Mac OS
X's API, it seems just as limiting as GNOME is now. Windows, on the
other hand, allows applications to register new events for it's sound
preferences UI and theming.

Storing these in GConf seems like a great way to get descriptive labels
in the preferences UI and on-the-fly configurability.

The main idea I have for an API is that applications only need to call a
function with an event name parameter (matching the GConf entry and
sample cache name), and a library will take care of everything. But
applications do need to provide the GConf schema.

> Rodney was working on such a spec. But I'll give you £50 if you manage
> to create/gather up a sound theme of quality matching the current
> gnome-audio sounds, and that's actually shippable without copyright
> problems by distributions.

Is that a bounty? Seems like a great way to involve more artists, no? :)

> PulseAudio should give you a separate track for the ESD connected
> applications. It's probably a matter of tagging those. Lennart would
> know better.

Good, I'll have to talk to him about it. I believe in PulseAudio
all-the-way, though. :)

Thanks,
- -- Stéphan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHRbnwcFUq0gzqDwQRAkidAJ9/dRUyuNFiFGOZKAeLdyJqSscTxACeLlmQ
9j8brUtR28pgORlHQFmRvh4=
=oN0y
-----END PGP SIGNATURE-----


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