[haiku-bugs] Re: [Haiku] #7285: BSoundPlayer sends buffers late, with ever-increasing latency

From: "marcusoverhagen" <trac@xxxxxxxxxxxx>
Date: Sun, 05 Jun 2011 09:32:04 -0000

#7285: BSoundPlayer sends buffers late, with ever-increasing latency
------------------------------+-----------------------
   Reporter:  Pete            |      Owner:  axeld
       Type:  bug             |     Status:  new
   Priority:  normal          |  Milestone:  R1
  Component:  Kits/Media Kit  |    Version:  R1/alpha2
 Resolution:                  |   Keywords:
 Blocked By:                  |   Blocking:
Has a Patch:  1               |   Platform:  All
------------------------------+-----------------------

Comment (by marcusoverhagen):

 Replying to [comment:2 Pete]:

 > First, MediaEventLooper and TimedEventQueue between them have a couple
 of bugs. There is a sign reversal in the test for lateness in ControlLoop
 (which when fixed reduces the problem but doesn't remove it), and the
 event queue suffers from a classic glitch ('classic' because I had to
 avoid it myself a long time ago...) in that if an event is placed in the
 queue while the loop is sleeping (maybe with B_INFINITE_TIMEOUT) the loop
 doesn't get woken up!

 I don't see a sign reversal in the lateness calculation. "Fixing" this
 will just make it schedule buffers later instead of (event latency)-early
 as it's intended.

 The queue won't get stuck because events are only placed in the queue from
 inside       BMediaNode::WaitForMessage, that means other nodes
 HandleMessage.

 Each time after WaitForMessage is processed, the first entrys in both
 queues are checked to account for modifications to the queue. Your patch
 completely removes this code. Why?

 The patch only tags realtime events that have a lateness >0 as realtime.
 Thats broken.

 The patch introduces a queued_time field, set on event creation. You even
 base the "lateness" calculation on that.
 But this is very strange. it should be possible to create 10 events, give
 them performance time stamps when they should be played, and place them
 into the queue. The are not late unless they get removed from the queue
 after their performance time has passed. Your lateness calculation makes
 them appear to be late, just because they were queued early.

 In: "lateness = 0;   // remove any extraneous value if we get this far "
 it appears your patch sets lateness always to zero before calling
 DispatchEvent, finally
 dropping the information how late the event is played. Why?

 I can't recommend applying this patch.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/7285#comment:28>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

[haiku-bugs] Re: [Haiku] #7285: BSoundPlayer sends buffers late, with ever-increasing latency

Other related posts: