When GNOME will be ported over from esound to using GStreamer everywhere?

The goal is that users can get sound events etc. and so on without using esound.

Today esound provides three things to libgnome: a simple play_file API, sound sample caching and remote sound playback. It also provides some well tested backends for a lot of different platforms.

GStreamer could easily provide the play_file API, and at the same time improve format support a lot, so that part is relativly easy to address. Since GStreamer have a esound plugin and also plugins for other popular soundservers the third item is also taken care of. The problem is what to do with the sample caching. When this has been discussed in the past the idea proposed was that there is some sort of API added in GStreamer which provides abstraction for sample caching with some kind of fallback when the underlaying system don't support it.

Especially this last item could be a lot of work, depending on how ambitious you are. The simples solution is not to cache when the underlaying system don't support it, and I am starting to feel this is the approach we should go for.

So anyway the job is relativly well defined, but since it touches core modules in GNOME which calls for extra carefullness and needs some GStreamer devel design work and implementation it has so far been something no-one either confident enough for and/or felt they have time for. So in terms of developer resources we are stuck between new contributors feeling the task a bit overwhelming and experienced contributors being swamped with items they feel are more critical.

We have a task entry for this in the GStreamer task list. This issue is also discussed on the Ubuntu wiki. The esound API can be found in gnome cvs.

Playback API

As mentioned above that would be relative easy. Basically wrapping playbin. However, you have to face with the "incompleteness of the GNOME API (see GStreamer/esd/DirectCalls)

Sound Caching

Can't we have a daemon that holds the sample cache together with a sample-cache-source gstreamer element that can deliver audio from the sample cache. The cache can deliver data straight from memory. It can also invalidate entrys in lowmem situations and make them available again on demand.

Network Transparency

Anyone some examples for playback over a network link? Looks like the needed elemnts are available in gstreamer already.

As far as my experience goes, networking was not easy with esd only. I just used esd over networking with manually launched esound that listens on a tcp port and then specifying the host with this daemon in the GStreamer GConf settings (I don't think there was any way to configure this in the past).

Can this perhaps be synced with the graphical side. Means if the display is routed to a different machine, try to connect to the running sound-server there.

Using libnofity and notification-daemon for sounds

There is one API thing that left untouched in this dicussion. The old gnome api is not about sound caching and sound playing, it's about events (triggers). We already have notification daemon that does exactly the same - notification about events. It's possible to change it so it will be able to play sounds with gstreamer also. I think we should discuss this idea and try to implement it.

http://www.galago-project.org/specs/notification/

Bango

This is where Bango could unify the desktop sounds:

http://freedesktop.org/wiki/Bango?action=highlight&value=sound

Responsible for that task

Btw, does someone work on this subject, it would be nice to advise it to some gnome lover?

Bugs about that problem, some of them have patches which can be a good start:

https://bugzilla.gnome.org/show_bug.cgi?id=324990

https://bugzilla.gnome.org/show_bug.cgi?id=94615

https://bugzilla.gnome.org/show_bug.cgi?id=82340

A try to implement the idea as discussed here can be found at https://bugzilla.gnome.org/show_bug.cgi?id=445078

Related Discussions

https://www.redhat.com/archives/fedora-devel-list/2004-October/thread.html#01473

http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00551.html

> > I think the answer to that is that GNOME should target GStreamer; apps use
> > the GStreamer source and sink provided from the GConf keys.  Then we
> > simply drop esound, and state that it is assumed that the target platform
> > provides sound mixing via one mechanism or another.  GNOME distributors
> > can change the default sink key.
>
> Won't that involve *everything* being linked to GStreamer via libgnome? (Not
> that I don't like the idea, but it has to be asked...)
Yes.
But the long term plan is to kill libgnome; when we push the sound event
handling into GTK+ via a plugin, we can probably engineer it so that the
plugin (which would link to GStreamer and GConf) is only loaded if sound
events are enabled (determined from an X property, propagated from GConf
via g-s-d)

about esound usage in Gnome,

http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00600.html