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

From: "Pete" <trac@xxxxxxxxxxxx>
Date: Fri, 11 Mar 2011 00:07:25 -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:  0               |   Platform:  All
------------------------------+-----------------------

Comment (by Pete):

 Replying to [comment:4 bonefish]:
 > Replying to [comment:2 Pete]:
 > > 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.)
 > > [...]
 >
 > [....] there are two usual reasons: 1. Handling an interrupt takes too
 long -- which really is a bug too (likely in a driver). 2. You have serial
 debug output enabled. The latter could explain all the behavior you have
 reported.   It might also explain that the latency increases over time,
 since late buffers cause the mixer to print to the serial debug output,
 which in turn worsens the issue.
 >
 > So, long story short, if you have serial debug output enabled (the
 default for nightlies and self-built images), try to disable it and see
 how things go.
 >
 Hah... and D'oh... I never suspected that -- because I wasn't aware that
 was the default for self-built images!  Serial-debug is suppressed in the
 alpha distributions, right?

 (I see several tickets, like #6709, that report the Mixer thread hogging
 the CPU.  Could this be a point people are generally not aware of?)

 Being brief as well... Things are much better now!  There is no runaway in
 the Mixer thread, and latency is fairly good.

 ''However'', they aren't perfect.  With default buffer_size (880 bytes for
 the MidiPlayer I think) latency still gradually increases, and the audio
 can suddenly get distorted (it "growls").  If I double the buffer size,
 latency still goes up (but less) and there is no growling.

 If I bring up Cortex and change the Run Mode to Drop Data, things seem
 much better still: latency stays at 18 msec.  I actually have not yet
 managed to hear the effect of a dropped buffer, so I'm wondering if this
 wouldn't be the better default.  Using BSoundPlayer, there seems to be no
 'official' way for an app to change the mode, so for my purposes I think
 dropping by default would be better, and I don't really want to keep a
 custom libmedia.so around!
 (I also notice that under BeOS the same apps ''don't'' suffer from
 drooping latency, so either BSoundPlayer there ''is'' dropping data, or
 they have a better algorithm.)

 >
 > Oh, and since you mentioned a perceivable latency, IIRC the last time I
 looked the multi-audio add-on played buffers a full buffer late. This
 isn't noticeable when just playing audio, but might be when watching a
 video or doing MIDI.

 I wonder if this is because the event queue is not woken up?  (Which I
 fixed for the SoundPlayNode, but has to be done for every module that uses
 TimedEventQueue.)  Or is there a totally different reason?
 In any case, with dropped data, latency is really good now.

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