Hello + sound event architecture

[Patryk Zawadzki]

Hi all,

I am new to the list and would like to introduce myself. My name is
Patryk Zawadzki and I am one of the PLD Linux developers.

This said, I'd like to ask a question (hope this was not discussed here
like two days ago as my internet connection is faulty and I am unable to
search through the mailing list archives).

Today most applications either rely on external programs like "aplay"
and "esdplay" or they use the desktop-specific sound frameworks directly
to handle their sound events.

We do have a working specification for icon themes so why not just adapt
a similar specification for sound events?

I originally started this as a bug in GNOME bugzilla but it does not
seem to be a good place for the discussion as I'd like freedesktop to
take care of that.

The idea is to create a robust sound event handling system based on DBUS
that would allow an application to tell the daemon to "play
gaim-user-online with priority of notification," let the daemon handle
the event and let the app forget about it completely.

To me such a daemon specification and a "sound theme" specification
would be a great start for even futher integration between various
desktop environments and between apps and their desktops as well.

The original bug is here:

http://bugzilla.gnome.org/show_bug.cgi?id=374073

For those not willing to click links, I will paste it below, the rest
can just ignore the rest of this post ;)

--- 8< ---

Create a new DBus-driven desktop sound event daemon. Not for playing
media streams, just to play the usual desktop sounds like "login,"
"logout," "IM user is online" and such.

As I see it, the daemon should make use of a directory tree similar
to /usr/share/themes, where there are "sound themes" and each theme is
split into a number of subdirectories like "apps," "actions" and
similar.

There should be a base theme like there is "hicolor" for GTK that allows
apps to provide their own generic sound events. Each theme could
override these sounds by providing a file with identical base name in
its own directory.

Similar caching techniques could be used as are currently in use for GTK
themes.

The DBus interface should provide a way to play a generic sound event by
name (without the extension, the daemon should be able to find a
matching file and use gstreamer to play it). This would allow for easy
handling of non-blocking event sounds in virtually all desktop
applications without relying on forking to  execute "aplay" or "esdplay"
as some do currently.

Additionally all sound should have a priority attribute, one of
"notice," "normal," "warning," "critical." Ideally the sound applet
should be able to talk to the daemon and tell it to suppress all sound
below a chosen threshold so I can opt to only hear critical events while
watching a movie in totem.

If you talk this over with freedesktop guys, this can provide perfect
interoperability between GNOME and KDE apps in the terms of sound event
handling.

Hope above is clear enough. Not sure where to post this so I just put it
under esound. Would love to hear your opinion on this.

Cheers,

-- 
Patryk Zawadzki <patrys at pld-linux.org>
PLD Linux