[gst-devel] sample caching

Christian Fredrik Kalager Schaller uraeus at linuxrising.org
Wed Nov 24 10:44:49 CET 2004

Probably me being stupid not seeing the problem being argued over here.
But here is my take on the situation.

I am assuming there is a method for deciding what gets cached or not
today. The logic for doing so must be somewhere already. If it is in
esound today I guess gstreamer just ouputs the sound to the sound server
and lets it handle wether to cache it or not as it has always done. If
it is in the esound library I guess the logic/code should be integrated
into the gstreamer cach dinging abstraction layer Iain is making. If the
logic is in libgnome I guess what we need to do is as part of Iain's
ding caching abstraction system have gstreamer forward the message to
cache from libgnome to the sound servers in question. If the underlaying
system do not support caching gstreamer simply discards the message to


On Wed, 2004-11-24 at 11:52 -0500, Colin Walters wrote:
> On Wed, 2004-11-24 at 15:23 +0000, Iain * wrote:
> > 
> > Well, there can be a boolean "cache" argument to tell the function to
> > cache the sample if possible. for playing my_30minute_song.ogg you'd
> > set it to FALSE.
> But you were talking about doing this for the existing gnome_sound_play;
> we can't change its API now by adding a boolean.

More information about the gstreamer-devel mailing list