The slightly simplified Clementine pipeline without those blocks and the event_probe looks like this:
[image: Clementine_simplified.png] On Monday, February 8, 2021 at 10:29:06 PM UTC+9 [email protected] wrote: > PS. Another question I has was about the probe_queue: why is it a queue2 > instead of a queue element ? From the documentation, queue2 should be used > when "networking buffering" is of concern. > Since such potential network buffering was already taken care of by the > pre-tee queue_ "queue2", this surely is no longer an issue at that point? > Besides, the audio_queue is itself a "queue" element > rather than a "queue2". In this case too, I replaced the the probe_queue > by a "queue" element with no apparent side effects. > > On Monday, February 8, 2021 at 10:22:28 PM UTC+9 [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/da4b42be-6486-4c09-927f-25751fa8ec73n%40googlegroups.com.
