Project

General

Profile

Bug #1725

Assertion failed in jitter timing class

Added by Peter Gusev about 6 years ago. Updated almost 6 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
#1

Updated by Peter Gusev almost 6 years ago

Got another assertion fail from NDNComm demo runs:

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

#4

Updated by Peter Gusev almost 6 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.

Also available in: Atom PDF