Hi. It looks like you're looking at a slightly out-of-date version of the code. The caps16 filter was definitely on the wrong side of the probe converter. Take a look at 25d3fca0 and the preceding commits.
I think you're probably correct about the dysfunctional callback. I don't see those log messages when I have them enabled. Some code archeology shows that this was introduced way back in 2013 during the update to gstreamer 1.0 (see 56c949815b). If you're studying the pipeline, you might be interested in a new debug feature. If you run with the CLEMENTINE_DEBUG environment variable set to 1, you can enter a debug console under extras. There's a mechanism there to dump a graph of the current pipeline as a dot file. On Mon, Feb 8, 2021 at 5:22 AM [email protected] <[email protected]> wrote: > Hi. > I am currently studying GStreamer and its application in Clementine. > > As far as I can tell, it currently looks something like in the figure > below: > [image: Clementine.png] > > My questions are concerning the two post-tee audioconvert blocks, which > seem completely redundant to me? > 1. Since the fakesink accepts ANY cap, the probe_queue can be connected > directly to the probe_sink, via the same filtered caps link that currently > exists between the probe_queue and the probe_converter? > 2. The audioscale_ "audioresample" block provides exactly the same caps as > the convert "audioconvert" block, thus it can be eliminated and audioscale_ > can be connected with the same filtered caps link that currently exists > between the convert and the audiosink_ block elements ? > > Or am I understanding caps negotiation wrongly? > Since audioscale_ and convert have the same caps, audiosink_ can negotiate > directly with audioscale_,. no? > > I know audioconvert blocks have virtually no overhead when no conversion > is necessary, but if those blocks are redundant, it would make the pipeline > schematic a little simpler. > > In any case, I have eliminated those two blocks without any negative > impact, it seems so far. Am I missing something for why these audioconvert > blocks better be there? > > My final remark on the pipeline is that the probe on the "event_probe" > element (which is either the pre-tee audioconvert or audioconvert2 element) > and its associated callback eventHandoffCallback are currently not > operating as probably intended: > The probe is setup to listen to UPSTREAM events, but eventHandoffCallback > only checks for GST_EVENT_SEGMENT, which is a DOWNSTREAM event. > > I posted a bug report for this: > https://github.com/clementine-player/Clementine/issues/6916 > > Since the visualizations seem to work OK and do not depend on the exact > timestamp info of the segments, which is apparently what the > eventHandoffCallback tries to achieve, the probe pointer event_probe, the > pad probe and its target callback function can be eliminated. which again I > did, with no apparent side effects. > Any counter indications ? > > Thanks for your thoughts/insight on this! > > -- > You received this message because you are subscribed to the Google Groups > "Clementine Music Player" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clementine-player/a2743b75-0b6e-4d8d-97d0-c4c49a44c42fn%40googlegroups.com > <https://groups.google.com/d/msgid/clementine-player/a2743b75-0b6e-4d8d-97d0-c4c49a44c42fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Clementine Music Player" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/clementine-player/CAKgEEwvcrbmfJLohdXMeFq8KDYYUSmuxEfms8BZ9Nbt7eRPxwA%40mail.gmail.com.
