[gst-devel] Negative overhead of multiple streams?

[Steve Fink]

I was doing a simple test to see what the overhead of firing off a
whole bunch of independent pipelines is. The result came out to be
negative. That's very efficient, but I'm wondering how my 8.673-second
clip managed to finish playing in 8.437 seconds.

My setup is that I create 32 independent pipelines, more or less like:

  uri-source ! wavparse ! audioconvert ! alsasink

Each has a different .wav file source, varying from less than 1/5
second long to 8.673 seconds long. I create them all, transition them
all to GST_STATE_PLAYING (and wait for them to finish transitioning),
then mark the current time. Then I run the main loop until all sounds
have finished playing, and mark the final time. I subtract those two
and report the difference. That's where I get the 8.437 seconds.

I also report on the stream time of each finished clip with
gst_element_query_position(). Those reports show that all of the
clips, including the long one, reached the end of their playback.

If I run with the single longest .wav file (or a small handful of
files, including that longest one), then it ends at about the right
time. It's only when I have a large number of them that things go too
fast.

The only thing I can think of is that the EOS is signaled as soon as
all data has been stuffed into an ALSA input buffer -- but if that
were the case, then it seems like those gst_element_query_position()
calls are returning wildly bad estimates. I thought gstreamer made
every effort to give an exact estimate of how many samples had reached
the line-out?

I'm guessing there's something I'm just not understanding here.

I tried to strip down my sample program and posted it at
http://0xdeadbeef.net/~sfink/gstreamer/gstest-simple.cpp

All of my input .wav files are in the same directory, or
http://0xdeadbeef.net/~sfink/gstreamer/gstest-simple-1.0.tar.gz will
give you everything. You'll need to run it with ALSA configured to go
through dmix to test this, because it depends on being able to reopen
ALSA 32 times.

I can file it as a bug, but first I wanted to check if there's
something obvious I'm missing.