Disclaimer

This is where I will put analysis and thoughts on GnomeAPI. Of course, you can correct it. But, the discussions will be held on GNOME Multimedia mailing list (http://mail.gnome.org/mailman/listinfo/gnome-multimedia).

To sum up, GNOME libraries (libgnome/gnomeui) are still esd centric, and esd does not support all of the today needs. http://live.gnome.org/GSmartMix/GnomeAPI is an insight of the current sound framework in GNOME. Here are some suggestions I would like to develop with you. I have taken time to examine source code rather than to read longly ml and bugzilla. Hence, these are only rough ideas based on current CVS code analysis.

Analysis

There is lacks of bugzilla links, comments and links. I will try to match and add them later.

Usage of sound API of GNOME

gnome-session (per host, sound functions are catched at start/end of the session)

If not already done, it starts the local esd server, and then initializes a local esd client. It (re)loads only the "login" sample (but not "logout"..). Both are later triggered off by gsm_sound_login()/logout() with the help of eg gnome_triggers_vdo("", NULL, {"gnome-2","login"}). But samples name for esd server are like this "gnome-2/login".

gnome-control-center/gnome-settings-daemon (per host, during all gnome session life)

Monitor "sound events" gconf parameters, and initialize an esd client side. After that, it will load common samples on the server (systemsounds and others listed in "sound properties" dialog), with not so well defined identifiers (gnome-2/name, gtk-events-2/name...). All that localy. Hence, correct me if I am wrong, local sounds files parameters are not "correctly" played on the remote esound server (they could be different parameters, so different sounds will be played). Is this a wanted side effect?

libgnomeui

It initializes esd client side with libgnome, and monitors "enable sound events" parameters. Then it registers hooks on gtk widget events (::activate/toggled/clicked) and message dialogs (::show). The relay function is called when events occur, thus triggers will be fired. I consider triggers are an *archaic and ugly* way of dealing with some kind of notifications (see code yourself). Finally gnome_triggers_play_sound() is called with the event sound name (btw, gnome_triggers_read_path()/readfile () seem to be dead code). The corresponding sound files must have been loaded previously by gnome-settings-daemon. If not, no sound will be hear. Correct ?

libgnome

Has you should have noticed, the gnome apps often have to bypass the GNOME layer. I have made a quick review of the direct call to esd at GStreamer/esd/DirectCalls. Basically, the GNOME sound API is an easy way to play "simple" sound files, with or without libaudiofile. The sound caching feature is incomplete: you have to call esd_sample_play() later (and track the caching in terms of memory usage, do some esd_sample_free() calls outside GNOME api). The sample type is not defined anywhere with this api (sample_name is not used, we don't differenciate events, music, voice and so on, Bango project is a soft dream). Except "gtk-events-2" and "gnome-2" class distinction (BTW, which are all gtk events). And gnome_triggers_read_path() is an ugly dead code, that used to load soundlist.

others...

• I am still wondering where is the code that handle Volume-Up/Down key binding. There is some bug I would like to report on this, because it doesn't follow the "volume applet" preferences of the track to control... Where shoud I report ? chpe: This code is in the gnome settings daemon in gnome-control-center.
• Ekiga uses PWLib to play sound events (archaic library for portability). Other sounds (voice...) are handled this way too, without GStreamer, nor GNOME system settings: GSmartMix won't work with Ekiga without changes. I hope someone from GStreamer will help fix this.

• Bango is really a nice project. I think that one goal would be to add a "Sound" panel in Theme preferences. Why don't we support sounds as we deal with icons (default and theme) ?

• *.soundlist files: how can they really continue to work today ? Related to these files, does the battery applet still emits sounds ?

esound

It offers:

• networked client/server architecture, but no modern streaming (see how we deal with streaming in nautilus): you could see --espeaker option in every gnome app, except settings-daemon
• sound sample caching feature, with bad memory handling
• software audio mixing, but no modern audio support
• some easy access to low audio related HAL calls
• low memory overhead for the client side
• mostly stable, tested and portable (detail: instead of start-stop, we use start-standby-resume for stability in gnome-settings)

GStreamer

Then comes multimedia applications, that rely on a better framework, GStreamer. So that they are able to play more formats, with more features and flexibility... (but don't forget that gstreamer-properties in the "System/Preferences" could be misleading since audio output preference is only related to GStreamer configuration, not esd. I had some confusion in the past on this)

Assessment

GNOME sound support is only a way to provide quick sound notifications, aka sound events. It can't reasonably compete with better API/architecture, like GStreamer. I also believe that current trigger mechanism is not completely necessary for sound, but I might be wrong (take a look at GTRIG_MEDIAPLAY and triggers_play_sound). I strongly suggest that Gnome API should only provide sound notifications mechanism, and GStreamer for any other usage. Open question: What is the boudary between notification-daemon, which offers sound option with notifications, and Gnome sound events API ?

However Ian FIXME has already done some work to consolidate the API. I believe he will add some extra functions to libgnome/gnomeui (so that we don't have to call esd directly). I can't wait to see your work and read your comments, Ian.

Proposal (in order to progressly drop esd)

I believe GNOME need its own tiny sound event daemon that feature the cache mechanism (for remote applications only and with file-caching scheme: not in memory). It will handle the local sound system theme loading/gconf monitoring OR it will simply play and cache sound files. The idea behind is that sounds could be loaded as are icons, with a net enabled daemon caching system on top of that. Furthermore, I think some race conditions will disappear this way between gnome-session and the sound daemon.

Daemon will rely on gstreamer to play sound samples (with esound sink if necessary). It will also handle net-streaming (with threads and GStreamer), in order to play remotely other streams.

For instance, if a remote host is set for rythmbox, the sound event file will be uploaded once when necessary and played remotly (thanks to GNOME api and this daemon). For the GStreamer playbin part, it should not use directly gconfaudiosink and the hidden autoaudiosink. Instead, a GNOME sink (maybe GSmartSink?) should read a global variable to know wether a remote connexion has to be established (kind of getenv() ?). Otherwise, it will fallback on local playback (with gconfaudiosink sink name underneath).

The difference with polypaudio is that it will support cache system, it will not be a "software audio mixer" and it won't support multiple inputs/outputs.