[gst-devel] New DXR3 components and scheduling problem

[Martin Soto]

Hi Ronald:

On Mon, 2003-03-31 at 16:31, Ronald Bultje wrote:
> On Mon, 2003-03-31 at 15:49, Martin Soto wrote:
> > I'm currently developing elements to write video, audio, and SPU
> > graphics to the Creative DXR3...
> ...
> > The idea is to complete a GPL'd Gstreamer based DVD player for the
> > DXR3.
>
> Offtopic question: will the plugins be LGPL? We prefer LGPL for plugin
> licensing. Of course, that's all your own choice, just a FYI.

I wouldn't mind making them LGPL is inclusion in Gstreamer requires it. 
I could still keep the main program GPL.

> I'm assuming the scheduler sees a connected queue and tries to fetch a
> buffer from either queue (and hangs on the first one) in the thread.
> Disconnect both the ac3 sink pad on the dxr3audiosink *and* on the
> mpegdemux ac3 src pad. Only then, the scheduler can be sure not to fetch
> buffers from the src pad and not to try acquire buffers for the sink
> pad. So both need to be disconnected.
> 
>                         +-----------------------------------+
>                         | Thread                            |
>                         |                                   |
>   +-------+ac3_stream   |  +-------+ ac3_sink +-----------+ |
>   |       |-----o   o---+--| Queue |---o  o---|           | |
>   | MPEG  |             |  +-------+          | DXR3Audio | |
>   | Demux |             |                     |  Sink     | |
>   |       |pcm_stream   |  +-------+  pcm_sink|           | |
>   |       |-------------+--| Queue |----------|           | |
>   +-------+             |  +-------+          +-----------+ |
>                         |                                   |
>                         +-----------------------------------+

Well, I tried that already and it doesn't work either.  The sole fact of
having two queues in the thread, even if one of them is completely
disconnected, seems to be enough to stop the flow of data to the sink. 
On the other hand, I've just seen that removing the idle queue
completely from the thread works (you can not destroy the object
however, since that leads to a segmentation fault).  I can use that
solution (removing the queue) as a workaround, but it makes things in my
program more complex in many respects.  I guess this is a bug in the
scheduler but correcting it is way beyond my current Gstreamer
knowledge.

> HTH, looking forward to your application!

Hopefully, I'll have a first release before the end of this week.

Thanks a lot!

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>