[gst-devel] New DXR3 components and scheduling problem

[Martin Soto]

Hello Ronald!

On Mon, 2003-03-31 at 16:54, Ronald Bultje wrote:
> On Mon, 2003-03-31 at 15:49, Martin Soto wrote:
> >         +-------+ac3_stream        ac3_sink +-----------+
> >         |       |----------o      o---------|           |
> >         | MPEG  |                           | DXR3Audio |
> >         | Demux |                           |  Sink     |
> >         |       |pcm_stream         pcm_sink|           |
> >         |       |---------------------------|           |
> >         +-------+                           +-----------+
> 
> On close inspection, why do you have two pads? Why not just one
(series
> of) 'audio' pad(s) that has both a audio/ac3 and a audio/raw mimetype?
> That's how plugins would handle this normally.

Well, actually my initial idea was two have just one pad, since the card
cannot play PCM and AC3 at the same time anyway.  I implemented the
whole stuff and it works (effectively using a pad that accepts both mime
types) except that after you play sound of one type, you cannot change
anymore to the other type.

Investigating the problem, I saw that the sink pad apparently locks
itself into the mime type that you used, and won't accept the other type
afterward.  That's a problem while playing DVDs, because there are DVDs
that change back and forth between the two types of sound (I have one
that uses AC3 for the menus, and PCM for the film, go figure...)

That's why I opted for the two pad solution, even despite of the fact
that the two pads are not intended to be used simultaneously.  But
probably I need to fix the pad linking and relinking stuff instead.

Cheers,

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