Re: Replacing esd with gstreamer

["Ian Burrell" <ianburrell gmail com>]

On 3/29/06, Andy Wingo <wingo pobox com> wrote:
> On Sun, 2006-03-26 at 20:57 -0800, Ian Burrell wrote:
> > The other places which used esound library directly were calling
> > esd_sample_free, esd_sample_getid, and esd_sample_play.  Basically,
> > the gnome_sound interface is not complete enough to work with samples.
> >  I think these uses can be removed by extending the gnome_sound API to
> > include gnome_sound_sample_free, gnome_sound_sample_getid, and
> > gnome_sound_sample_play functions.
> >
> > The samples are stored in the esd server itself.  My feeling is that
> > it would be acceptable to load the samples in the application and not
> > share them.  It might make sense to have an interface in gstreamer to
> > load samples into different sound servers and play them but I don't
> > think that is required for the migration.
>
> This probably will not work. Think every application on the desktop
> linking to gstreamer and initializing it every time they start up, think
> the sounds when you roll a mouse over a menu being stored (and possible
> cached) in every process... Good intentions but I don't think this is a
> good idea.
>

I am worried about the overhead of loading gstreamer.  I am also not
sure about the overhead of building the gstreamer objects to cache the
samples.  Also, it would simplify playing multiple sounds at one time
if only one program needed to worry about them.

> I could be wrong, but I don't think ESD can be replaced without writing
> a daemon. I think you could probably get away with requiring
> multiple-open on the hardware to start up the daemon, so that you
> wouldn't need to write a sound server -- apps would just write to the
> sound card, using the normal API, relying on the system to mix them --
> but a daemon it should be.
>

There is a need for daemon right now since the samples for the event
sounds are loaded by the gnome-settings-daemon.  The sound event
config is not stored in gconf. They are in property files named
.soundlist in /etc/sound/events and $HOME/.gnome2/sound/events.
Loading the sound samples by each process if they haven't been
pre-cached in the sound server would fix some issues, like the sound
events being lost if esd is restarted.  This would also allow
process-local sample caching to work.

I thought of one solution which would be a very simple dbus daemon
which would basically implement the gnome_sound API.  The notification
daemon dbus API might also work although it is more oriented toward
popup notifications and hacking it for playing GUI and game sounds is
probably wrong.

> Regarding accessibility, the events that would cause sound to be emitted
> should send off the proper accessibility notifications from the side of
> the application. That's the only way to serialize them properly. I
> assume there is no global accessibility arbitration daemon running --
> pretty ignorant about all this, I am.
>

I think the accessibility hooks into the events separately. And gok at
least will play sounds through gnome_sound API.  The other main use of
event sounds is in gnome-games.

 - Ian