And more GST RTP stuff...
Continuous clock-drift compensation (prio:medium;v1)
----------------------------------------------------
Clock drift will always be an issue when a receiver node is
consuming a stream of RTP packets created in real-time by
a sender node. This drift is caused by speed differences
between the sender/receiver clock (or clocks, for example system
and audio device clocks might be different) and the nominal rate
of the stream (for example 8000 samples per second for G.711).
The speed difference will in most cases be different for the
sender (Dsender) and the receiver (Dreceiver). Additionally,
any of the clocks may drift more with time (D(x) > D(x')).
The short term solution for clock-drift is documented in
the item 'Codec independent playout buffer element'. The idea
is to detect the drift condition, and perform a resync
(essentially restart the reception, treating the most recently
processed packet as the first packet of the stream).
The mechanism described above will allow the stream reception to
continue even in the case of the drift, but will cause periodic
audible artifacts to the reception.
To fully solve the problem, the receiver must be able
to continuously adapt to the drift. In gstreamer, this
can be accomplished with the master-slave clock architecture.
The elements receiving RTP packets will create a master-clock
element for the pipeline, and the sink element in the
pipeline will be slaved to this master clock.
Rationale:
- To allow glitch-free playback even in the case of
severe clock-drift between sender and receiver, the
receive processing chain should be able to continuously
adapt to the clock-drift.
Open issues:
- Must the master-clock (derived from incoming packets) be
used as the pipeline clock, or can it be used just for
the udpsrc->sink flow of data?
- Can a accurate enough clock be created from a RTP
packet stream with significant jitter, and occasional
large delay spikes caused by routing changes?
- How processing intensive is the slaving code in
<gst-plugins-base-cvs/gst-libs/gst/audio/gstbaseaudiosink.c>.
Alternatives:
- Handling the drift internally in the playout buffer by
a) resampling, or b) adding/remove samples periodally,
to adjust for the drift.
--
under work: Sofia-SIP at http://sofia-sip.sf.net
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Farsight-devel mailing list
Farsight-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/farsight-devel
