On 2013-04-20 17:09, Christian Vogler wrote:
Mark,
can you describe exactly how the link to Section 6.5 solves the
problem of <w> interval backlog? The last version I saw made Section
6.5 look like a suggestion (clients "can" ....), rather than something
that is mandatory. I might not be up to date with respect to the most
recent changelog there - but based on experience I now believe that
implementing it has to be mandatory, rather than optional.
In order to avoid both jerky playout and excessive delay, I want to
propose the algorithm for catch up in 6.5 to be changed from
"Recipients can avoid excess lag by monitoring the queue for excess <w/>
action elements (e.g. unprocessed <w/> elements from two <rtt/> elements
ago) and then ignoring or shortening the intervals in <w/> elements."
"Recipients can avoid excess lag by monitoring the queue for unprocessed
<w/> action elements from more than one <rtt> elements, and then
shortening the intervals in <w/> elements so that the sum equals the sum
of <w> elements in the latest <rtt> element."
I think that is the best way to handle jitter in a smooth way.
6.5 is not mandatory, so it would be interesting to see how well it is
encouraged from section 4.
Gunnar
Christian
On Thu, Apr 18, 2013 at 6:57 PM, Mark Rejhon <marky...@gmail.com
<mailto:marky...@gmail.com>> wrote:
Addendum:
On Thu, Apr 18, 2013 at 6:39 PM, Mark Rejhon <marky...@gmail.com
<mailto:marky...@gmail.com>> wrote:
*WORTHY -- BUT POSTPONE TO 2014*
It makes a lot of sense but I'm going to postpone this change
for now, because of unanticipated side effects of minor
wording tweaks.
Both me and Chris treat <w> intervals accumulating on a system
time since the beginning of <rtt>, so slow local performance
doesn't cause <w> to
Incomplete sentence noticed; completing it as:
Both me and Chris treat <w> intervals accumulating on a system
time since the beginning of <rtt>, so slow local performance
doesn't cause <w> to cause a backlog. Even if it did cause a
backlog, handling for backlogged <rtt> (which is the bigger
problem and chief cause of lag), that is already written in the
spec (with improved wording), can already adequately handle this
scenario in XEP-0301 clients that used a "wait since last action
element" methodology."
In other words, the problem is already indirectly solved by the
Version 0.8 of XEP-0301 (existing section 6.5)
--
Christian Vogler, PhD
Director, Technology Access Program
Department of Communication Studies
SLCC 1116
Gallaudet University
http://tap.gallaudet.edu/
VP: 202-250-2795
