I have pipeline which sends audio from .wav file via RTP to VoIP server
(with help of rtpbin element), and at the same time receives audio from
it and saves it to another wav file. I wanted to measure delay
introduced by VoIP server, by saving both input audio and output audio
to separate channels of .wav file. To do this, I split decoded stream
from .wav file into two using tee, and then send it to interleave
element (plus necessary audioconvert/audiopresample/capsfilter) as
channel 1. Channel 2 gets decoded rtp stream.
When I opened recorded file, I found that delay is about 5 secs, plus
similar part of initial audio on channel 1 was truncated. GStreamer
itself introduces small delay - on all 3 paths (filesrc->udpsink,
udpsrc->filesink, filesrc->filesink) it is below 1ms. I also decoded
captured RTP streams in Wireshark, and delay between them was 23ms. So
things clearly do not sum up.
Looks that this is synchronization problem. I added sync=TRUE to
filesink, what cut down about 1 sec. I also added audiomixer +
audiotestsrc as silence generator after rtpbin and decoders to always
have this part of pipeline connected - before I had to wait for signal
from rtpbin that it added corresponding output pad. Now delay in
recorded file is about 2 secs, what still is way too big.
Looks that my streams are still not properly synchronized. What am I
I also still see that initial audio truncation. I stop pipeline by
changing state to NULL, so file is not closes properly and some trailing
audio is lost. Is is possible that initial part can be lost too because
BTW, I have just noticed that GStreamer provides interleave and
audiointerleave elements, and it seems that both of them do the same
thing. Why 2 similar elements exists?
interleave element is deprecated and you should use audiointerleave instead.
audiointerleave element is written on top of GstAggregator which works very
well for live inputs unlike the interleave element
Thanks! audiointerleave element works much better, looks that both
streams are synchronized now. It also seem that delay introduces by
jitterbuffer is removed.
However beginning of stream coming from tee element is still truncated -
about 3.2 secs of initial audio is replaced with silence. I have queues
added before both sinks of audiointerleave, so it is surprising to me.
What am I doing wrong?
Le jeudi 17 mai 2018 à 18:22 +0200, [hidden email] a
> Thanks! audiointerleave element works much better, looks that both
> streams are synchronized now. It also seem that delay introduces by
> jitterbuffer is removed.
> However beginning of stream coming from tee element is still truncated -
> about 3.2 secs of initial audio is replaced with silence. I have queues
> added before both sinks of audiointerleave, so it is surprising to me.
> What am I doing wrong?
I'm not sure, maybe because of the start time. You may want to try with
start-time-selection=1. Sometimes adding some latency (See "latency"
property" resolved some timing issues).