[gst-devel] queue full patch in 0.6.1?

[Martin Janzen]

Colin Walters wrote:
> Since bugzilla appears to be down I'll just send this here.  Basically,
> for netRhythmbox, I need a way to buffer (e.g.) 32k of data before
> actually playing an iradio station, like xmms.  This is to smooth out
> network jitters.
> 
> So my pipeline looks like this:
> 
> { gnomevfssrc ! queue } ! decoder  ! volume ! sink
> 
> Now, my approach is to start the "srcthread" (the first thread part) to
> PLAYING, and wait until the queue fills up.  When I get the queue full
> signal (see below), then I set the whole pipeline to PLAYING.
> [gst-queue patch]

Colin, I posted a similar patch a while back; see:

    http://bugzilla.gnome.org/show_bug.cgi?id=108268

That patch added a "min_threshold_bytes" property to the gstqueue, so 
that if the queue is empty and the reader (downstream) thread is blocked 
waiting on data, the queue doesn't unblock the receiving thread the 
moment that input is received, but waits until the queue fills to the 
threshold.  The idea is to avoid "scraping bottom":

Before:              After:

                        +--------- block reader thread
                        |      +-- signal reader thread
                        |      |              /
                        v      v             /|
                                   /   min_threshold_bytes
                      - - - - -/- /|- - - -/- | - - - - - -
                              /| / |  /   /   | /  __
                             / |/  | /|  /    |/| /   etc.
                            /      |/ | /       |/
    /   /    ^          /  /          |/
__/|__/|___/|__      _/|_/


Your signal on a full queue works too; but then you might get the 
opposite problem on the top end of the queue: the writer (upstream) 
thread blocks and unblocks frequently every time the reader removes 
something from the queue.  A threshold lets you stay in the middle, 
which is where you want to be.

Future variations on this could include thresholds based on time rather 
than number of bytes, which would better handle a variety of input 
bandwidths; and low/high watermark signals which allow you to manage the 
queue on the fly, eg. by "steering" the stream-timestamp-to-system-clock 
mappings.  Wim has suggested some sort of pluggable mechanism, which 
would be great, but I'm not quite sure yet what the interface should 
look like.  (I do have a simple low/high watermark patch against 0.6.0, 
which I can send you if needed, but haven't cleaned it up enough to 
submit "officially".)

Anyway, I haven't had a chance to try 0.6.1 yet, so I'm not sure whether 
the #108268 patch made it or not; but you can always grab it from 
Bugzilla and give it a shot if you're interested.  Feedback and 
discussion welcome...

-- 
Martin Janzen
janzen at pixelmetrix dot com