Caching sounds with GStreamer [WAS: Re: Proposal: replacing esound with polypaudio in 2.10]

[Maciej Katafiasz <mnews22 wp pl>]

Dnia 29-10-2004, pią o godzinie 17:25 +0100, Iain * napisał:
> 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.

this sounds very nice, and also trivial to implement with almost no
changes to API (besides adding "can-cache", and probably also "should-
cache" props)

> --------------------------------
> 
> 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...)

while this IMHO calls for separate interface along the lines of
GstXOverlay, appropriately named GstAudioCache

Perhaps, for the sake of simplest use-cases, we could also add somewhat
hackish write-only prop "uncache" which would take sample ID, and make
implicit assumption that all samples get uncached on app shutdown /
pipeline destruction, depending on exact lifetime cycle of pipeline. But
then again, since gnome_play_sound() is bound to know GStreamer anyway,
all the hackery is probably pointless and GstAudioCache is only thing
that's needed :)

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 wp pl>
         http://mathrick.org