[gst-devel] sample caching

[Colin Walters]

On Tue, 2004-11-23 at 23:17 +0000, Iain * wrote:

> You can't use a dedicated element to cache the samples, because the
> samples are not cached in the pipeline.
> 
> consider
> 
> filesrc ! spider ! polypsink
> 
> polypsink is connected to the polypaudio daemon.
> It is this daemon which does the caching, not the polypsink. The
> caching of the sample is not to reduce the time spent in the spider,
> it is to reduce the time going from the polypsink->polyp daemon. So a
> GstCacheElement would not help there.

Right.

> As to Colin's issue. We could create a function
> "gst_bin_get_real_sink"[1] (I've implemented a similar function for
> part of Marlin) which returns the real sink given a GstBin.

Ah, that makes sense.

> In my ding caching stuff that I've been quietly working on 

Cool; does it work via an interface on a sink, or something else?

> (slowly,
> it's essay season), would use such a function, but the user of the
> ding caching would just call gnome_sound_play [1] and everything is
> taken care of for him.

Hmmmm.  I'm not sure that's such a good idea.  How do you know when to
cache sounds and when not to?  If I play a 20MB ogg via
gnome_sound_play, will that be cached?  For how long?

> [1] All function names are subject to "Iain, your ability to name
> functions sucks!"

Heh.  I'd probably call it gst_bin_get_sinks, because in general a bin
could have more than one "terminal" sink, right?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20041123/4a3c98f9/attachment.pgp>