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

From: "Pete" <trac@xxxxxxxxxxxx>
Date: Thu, 10 Mar 2011 03:19:39 -0000
#7285: BSoundPlayer sends buffers late, with ever-increasing latency
-----------------------------+-----------------------
   Reporter:  Pete           |      Owner:  nobody
       Type:  bug            |     Status:  new
   Priority:  normal         |  Milestone:  R1
  Component:  Audio & Video  |    Version:  R1/alpha2
 Resolution:                 |   Keywords:
 Blocked By:                 |   Blocking:
Has a Patch:  0              |   Platform:  All
-----------------------------+-----------------------

Comment (by Pete):

 I've been digging into this for the past couple of weeks, and have made
 some progress, but I don't really think I've reached down to the root
 cause.

 First of all, if I increase the buffer size from the 'suggested' one
 (which BSoundPlayer normally uses) the problem goes away.  And I notice
 that MediaPlayer's audio buffer is larger still, so I imagine this is why
 it doesn't glitch.  However this means I'm not going to get the best
 latency, which is important for real-time playing of MIDI from a keyboard.
 It's actually not too bad -- around 22 msec -- but Haiku ought to be able
 to do better!  (The lag is still noticeable.)

 I've been putting in (and removing...) printfs everywhere, to see if I can
 pinpoint the real cause of the delay, but I tend to get a headache poring
 through the resulting reams of output! (:-/)  I have found a few things
 though.

 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!  As port messages do typically arrive regularly,
 things get handled eventually, but not always as soon as they ought to be.
 I'll report all this more fully later, when I get it into patch form.

 What I find completely mysterious, though, is -- what may be the root of
 the whole problem -- that the read_port_etc in WaitForMessage (called in
 MediaEventLooper's ControlLoop) sometimes times out 4-8 msec late! (About
 the same amount the latency keeps increasing by.)

 I put the following printfs around the read_port_etc in WaitForMessage
 (MediaNode.cpp):

 {{{
         printf("WaitForMessage at %Ld timeout at %Ld\n", system_time(),
 waitUntil);
         ssize_t size = read_port_etc(ControlPort(), &message, data,
 sizeof(data),
                 B_ABSOLUTE_TIMEOUT, waitUntil);
         printf("read_port_etc return %ld at %Ld\n", size, system_time());
 }}}

 and -- just occasionally -- catch something like this:

 {{{
 WaitForMessage at 14447043832 timeout at 14447044247
 read_port_etc return -2147483639 at 14447052271
 }}}

 Note that the time of return is 8 msec later than requested!
 I don't imagine this is expected behaviour in a B_URGENT_PRIORITY task?

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/7285#comment:2>
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:
