Re: Proposal: replacing esound with polypaudio in 2.10

[Iain * <iaingnome gmail com>]

> I consider it "truly important". When using X11 and the sound server
> over a network you don't like the extra latency you experience
> everytime a bell event is generated by your terminal.
> 
> I like the idea of using GStreamer as a comprehensive abstraction
> layer for caching event sounds. This would allow me to use Polypaudio
> as underlying sound server even in case Polypaudio is not adopted
> by Gnome. And this would make it easier for the KDE people to agree to
> a common solution with Gnome.

This is an idea that I came up with while having this discussion with
Christian and Ronald

How GStreamer could be modified to provide Ding-Caching.

We have a function which for the sake of arguement is called
gnome_sound_play, and it takes one arguement, the name of the sound
sample. This function is a simple wrapper around running a gstreamer
pipeline that consists of

filesrc ! decoder ! audiosink

Now, each specific audiosink knows if it is able to cache sounds or
not - polpysink and esdsink are, osssink and alsasink are not. My
first change to make to the sinks is that they
have a property called "can-cache" and this is either TRUE or FALSE
depending on the sinks ability to cache. The second change to the
audiosinks is that a signal is added called "cached" which is fired
whenever a sample has been cached. This signal would return a Cache ID
which would uniquely identify the sample in the sink's cache.

The two use case scenarios.

1: The sink's "can-cache" property is set to FALSE (eg: alsasink and osssink)
    In this case every call to gnome_sound_play will feed the filename to the 
    filesrc ! decoder !  audiosink pipeline and play it. There will be
no caching, and
    all the associated latency/bandwidth issues.

2: The sink has a TRUE "can-cache" (eg: esdsink and polypsink)
    In this case gnome_sound_play first looks up the filename in a
table to see if it has
    already been cached. If it has not, then it acts like the first
case, except this time, the
    "cached" signal is emitted and gnome_sound_play stores the cache
ID for future
    cache use.
   
    If the file has already been cached then an event with the cache
ID as payload is
    injected into the pipeline, which tells the sink to just play the
cached sound associated
    with the cache ID.

--------------------------------

Pre-caching:
A second function: gnome_sound_cache ("filename.mp3") would be used,
which is a NOP if the sink cannot cache sounds. If it can cache
sounds, the sink is instructed that the
next sound it receives is NOT to be played, only cached. In this case
it acts just like gnome_sound_play when an uncached sound is played,
but without the noise.

Are there any other requirements for sound caching? Removal of a sound
from the cache, prevention of caching a sound (I don't really want my
37 minute GY!BE mp3 cached in my sound server really...)

I guess this email is just to show that ding-caching can be done with
GStreamer if it needs to be.

iain