Re: System event sounds / audio feedback

[Bastien Nocera <hadess hadess net>]

On Thu, 2007-11-22 at 18:18 +0100, Stéphan Kochen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bastien Nocera wrote:
<snip>
> 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.

Which is why I said "stop-gap" :)

> > 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. :)

Fedora's is the same as the upstream gnome-audio.

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

That's because it completely replaces it, and there's no theme support.
Unless we have a good core set of sounds, theme support makes no sense.

> > 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.

It's a bug. Pulseaudio doesn't know whether a particular connection is
used for sound events, or for movies or music.

> >> 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.

We never talked about adding sound handling, but you need triggers,
otherwise the module that actually does the sound won't know when to
push a specific sound.

> > 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.

It's also a good way to ensure you never have a theme that matches the
whole range. Your nice jungle sound theme will be interrupted by a loud
car crash sound left-over from another theme when some app crashes.

You don't need a different sound for a standard error popup in different
apps (_standard_ I'm not talking about a CD burn failing, or
out-of-battery errors). Limiting the number of sounds in the default
API, while keeping the ability of apps overriding it means that most
applications developer will use the stock items.

Providing an interface to allow users to change the default is a good
idea though (as opposed to each application providing that interface).

> 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.

Not all GTK+ apps use GConf. See any xfce app, or the GIMP. But you're
getting ahead of yourself, thinking of implementation details (because
it doesn't really matter whether that data is in GConf or a flat .ini
style file).

> > 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? :)

I'm still waiting :)

> > 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. :)

Again, it doesn't matter whether it uses the ESD compat API, or
PulseAudio. PA needs a way to tag those streams as special.

Cheers