Project

General

Profile

Actions

Bug #1725

closed

Assertion failed in jitter timing class

Added by Peter Gusev almost 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Bug
Start date:
07/01/2014
Due date:
% Done:

100%

Estimated time:

Description

Need to explore causes for the failed assertion in jitter-timing class and fix it:

Assertion failed: (0), function startFramePlayout, file /Users/peetonn/Documents/Work/CCN/ndnrtc/cpp/src/jitter-timing.cpp, line 64.


Files

assert-1.log (157 KB) assert-1.log Peter Gusev, 08/29/2014 04:41 PM
assert-2.log (160 KB) assert-2.log Peter Gusev, 08/29/2014 04:44 PM
Actions #1

Updated by Peter Gusev over 9 years ago

Got another assertion fail from NDNComm demo runs:

assertion failed: prevIterationProcTimeUsec (1013) < framePlayoutTimeMs_*1000(42000)

Actions #2

Updated by Peter Gusev over 9 years ago

Actions #3

Updated by Peter Gusev over 9 years ago

Actions #4

Updated by Peter Gusev over 9 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

The problem was happening after rebuffering and playback recovery: whenever consumer experience break in packet delivery it switches back to chasing mode. Once consumer get to the Fetching mode (after successful chasing) it starts Playout mechanism which initiates JitterTiming which uses timer.
Sometimes, Event::Wait call in timer didn't return after allowed time and thread stayed suspended, that's why whenever consumer starts new playout thread there are actually two playout threads: one which is newly started and the other one which was suspended on timer. New thread makes calls to the same timer entity which eventually triggers suspended thread and at this point there are two playout threads which are running concurrently.
The problem was solved by explicitly calling stop on JitterTiming instance inside playout mechanism.

Actions

Also available in: Atom PDF