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

#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 bonefish):

 Replying to [comment:5 Pete]:
 > Replying to [comment:4 bonefish]:
 > 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?

 Yep.

 > ''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.)

 To avoid misunderstandings, both modes drop buffers, if they are too late
 for being processed/played in time. The "increase latency" mode
 additionally increases the latency, if buffers are late. I believe it does
 so also, when the buffer arrives late, but the node decides that it can
 still process it in time. If you don't hear dropped buffers (or see them
 in the syslog), then this is likely what happens. Since the "drop buffers"
 mode works fine, there's likely a bug in the code related to latency
 increase computation or in the code of the upstream nodes handling the
 latency increase. I already mentioned one common mistake that can lead to
 things getting continuously worse: Mix-up of real and performance time in
 computations. Another issue could be a bug in the lateness computation
 somewhere in the `BMediaEventLooper` code. `ControlLoop()` looks
 suspicious IMO. It apparently computes the lateness after pulling the
 event out of the queue. I believe it should do that directly after the
 buffer arrives.

 > > 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?

 It's a logical problem in the multi-audio add-on itself. It simply
 schedules the buffers for playing one full buffer late.

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

Other related posts: