<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
we just debugged dynamic linking issues during the hackfest. Do
you have a standalone (minimal) repro?<br>
<br>
Stefan<br>
<br>
On 03/17/2014 07:55 PM, <a class="moz-txt-link-abbreviated" href="mailto:marcin@saepia.net">marcin@saepia.net</a> wrote:<br>
</div>
<blockquote
cite="mid:CA+DLCvCA_oTMLsPnM+7yi_uSEX2v-OxT5QbNRdLcSSJLxzo5-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>I have found out two things that may be helpful:<br>
<br>
</div>
1. that removing audiorate fixes the problem (although the
audio starts to contain drops), and just after RTP branch
reaches PLAYING, audiorate starts to insert a lot of samples<br>
<br>
</div>
<div>2. that delay is close to difference between running times
of different branches of the adder. I've created test branch
with audiotestsrc, and then added RTP branch. This is what
happens in the logs in such case:<br>
</div>
<div><br>
0:04:53.002670391 4078 0x1c18a80 LOG
audiorate
gstaudiorate.c:496:gst_audio_rate_chain:<test_audiorater>
in_time:0:04:53.894965986, in_duration:0:00:00.023219955,
in_size:4096, in_offset:12960768, in_offset_end:12961792,
->next_offset:12960768, ->next_ts:0:04:53.894965986<br>
0:04:53.002735134 4078 0x1c18a80 LOG
audiorate
gstaudiorate.c:505:gst_audio_rate_chain:<test_audiorater>
within tolerance 0:00:00.040000000<br>
0:04:53.002916372 4078 0x1c7b320 LOG
audiorate
gstaudiorate.c:496:gst_audio_rate_chain:<livertp_audiorater>
in_time:0:04:31.490257990, in_duration:0:00:00.020000000,
in_size:3840, in_offset:13031532, in_offset_end:13032492,
->next_offset:13032481, ->next_ts:0:04:31.510020833<br>
0:04:53.002952270 4078 0x1c7b320 LOG
audiorate
gstaudiorate.c:505:gst_audio_rate_chain:<livertp_audiorater>
within tolerance 0:00:00.040000000<br>
<br>
</div>
<div>During the delay, audiorate inserts multiple empty frames:<br>
<br>
<livertp_audiorater> inserting 48000 samples<br>
</div>
<div><br>
<br>
</div>
<div>I would be glad if anyone could help me in resolving this
odd case...<br>
</div>
<div><br>
</div>
m.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-03-17 17:47 GMT+01:00 <a
moz-do-not-send="true" href="mailto:marcin@saepia.net">marcin@saepia.net</a>
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:marcin@saepia.net" target="_blank">marcin@saepia.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>Hi,<br>
<br>
I have a pipeline that is basically<br>
<br>
adder ! pulsesink<br>
<br>
then I create dynamically a new branch. It is RTP
source:<br>
<br>
</div>
rtpsrc ! rtpjitterbuffer do-lost=true !
rtpvorbisdepay ! vorbisdec ! queue2
max-size-bytes=16384 ! audiorate ! audioconvert !
audioresample ! tee ! queue2 max-size-buffers=64 !
fakesink<br>
<br>
</div>
I put this branch to the separate bin, set state as
PLAYING and wait for user input.<br>
<br>
</div>
When user wants to enable it, I request new pad in
adder, request new pad in branch's tee, create
appropriate ghost pads and link it.<br>
<br>
I am able to hear data coming through RTP.<br>
<br>
</div>
<div>But I've found out that the latency increases each
time I disconnect and reconnect new branch. I hear that
the sound is delayed. It is almost not delayed if I add
RTP source branch immediately at the initialization of
the app, but it gets delayed if I reconnect it or just
add a bit later. The latency is up to a few seconds.<br>
<br>
</div>
<div>I've run the app with GST_DEBUG parameter and the
only suspiciable thing I've found out is related to the
pulse sink. In between linking the branch and moment in
which I actually hear the sound such messages appear<br>
<br>
0:00:07.917924339 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:07.917953114 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 158, out 158<br>
0:00:07.918454156 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:07.918490613 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 43940, out 43940<br>
0:00:07.920271008 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:07.920310888 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 44099, out 44099<br>
2014-03-17 17:35:48.978 [APP APPTHREAD DEBG] [Source
"livertp" PREPARED] Buffer levels (read_buffer): 5/0
buffers, 19200/16384 bytes, 00:00:00.098/00:00:00.000<br>
0:00:08.132638374 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:08.132677764 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 44099, out 44099<br>
2014-03-17 17:35:49.980 [APP APPTHREAD DEBG] [Source
"livertp" PREPARED] Buffer levels (read_buffer): 5/0
buffers, 19200/16384 bytes, 00:00:00.098/00:00:00.000<br>
0:00:09.106877139 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:09.106908428 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 44099, out 44099<br>
2014-03-17 17:35:50.981 [APP APPTHREAD DEBG] [Source
"livertp" PREPARED] Buffer levels (read_buffer): 5/0
buffers, 19200/16384 bytes, 00:00:00.098/00:00:00.000<br>
0:00:10.145079271 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:10.145115239 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 44099, out 44099<br>
2014-03-17 17:35:51.982 [APP APPTHREAD DEBG] [Source
"livertp" PREPARED] Buffer levels (read_buffer): 5/0
buffers, 19200/16384 bytes, 00:00:00.098/00:00:00.000<br>
0:00:11.099619090 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.099658900 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 25990, out 25990<br>
0:00:11.733816986 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.733851977 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.734504784 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.734524758 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.735202987 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.735222752 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.735860753 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.735880239 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.802681891 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.802717371 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.803579910 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.803597929 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.804552798 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
0:00:11.804574659 20423 0xe22d40
DEBUG pulse
pulsesink.c:1458:gst_pulseringbuffer_commit:<tmpsink>
in 881, out 881<br>
0:00:11.875740692 20423 0xe22d40
DEBUG pulse
pulsesink.c:1440:gst_pulseringbuffer_commit:<tmpsink>
entering commit<br>
<br>
<br>
</div>
<div>I've noticed that numbers in lines such as " in
44099, out 44099" are higher when this scenario occurs.
When everything works ok they are equal to 881.<br>
<br>
</div>
<div>How to interpret that or what else can I do in order
to find what is causing the delay?<br>
<br>
Thanks,<br>
<br>
m.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>