[gst-devel] patch adder plugin

[Jim Thornton]

> Actually, the adder is designed to put out zeroes if nothing is
> connected to it on the sink side. It's a feature of sorts; think of the
> case where you want it to act like a mixing bus.

Yes, I agree.  In fact, I think that this is the behavior that I want in the
long run.  I got distracted by the problem of trying to get the pipeline to
stop.

> However, I do see where you would want this behavior in an adder, I
> think it should be implemented as a property, say 'eos-behavior'. One
> behavior would be the current way of doing things, another would be to
> pass along eos when any of its 'feeders' emits eos, and another would be
> only to emit eos when the last feeder does so, as your patch appears to
> do.

In practice, however, everything stops when the first eos comes through
which is a bit mysterious to me :-(

So here's the problem:  if I run two filesrc's into an adder (through parse
and volume) then when the first file runs out I get an EOS callback as
requested (by g_signal_connect() on the filesrc for "eos") but thereafter
the pipeline runs forever without ever returning from gst_bin_iterate() and
without ever producing any more sound from the file that hasn't run out.  My
application never gets control again.  My first thought was that the adder
needed to respect the EOS signal and stop but with your good observation and
more reflection and testing I now believe that there is just a bug, probably
in the basic scheduler that is causing it to "lock on" to the filesrc when
it starts producing EOS signal-buffers out of the get.

Thanks,

Jim