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

  • From: "jua" <trac@xxxxxxxxxxxx>
  • Date: Sun, 13 Oct 2013 10:45:47 -0000

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

Comment (by jua):

 I think I have a a good solution which I will implement.

 While I find working around the timing inaccuracy shouldn't be necessary,
 there's another thing I had not thought about when writing the previous
 comment: virtual machines. Those were slow and not popular in Be's days,
 but certainly are today. When running an OS in these, timekeeping is known
 to be less accurate. So it makes sense to be more resilient against timing
 inaccuracy in MediaKit and use `queued_time`.

 However, I wouldn't like to just hide the problem, we should generally
 keep an eye on keeping timing as accurate as possible, it's one of the
 things Haiku can excel at in a desktop system. Imagine the case of a user
 who wants to use Haiku for playing software-synthesizers via a MIDI
 keyboard. For a skilled player, 8ms additional latency can make all the
 difference in the world. Now if he has a system plagued by blackouts of up
 to 8ms, he would see his latency being increased and wonder why that
 happens and it would be hard to tell ''why'' the MediaKit decided to
 increase it.

 The solution I want to go for is this: use the `queued_time` for lateness
 calculation, that way the seamlessness constraint is always met, and even
 in virtual machines or with broken drivers, things do work (although with
 increased latency). But then, in `BMediaEventLooper::ControlLoop`, we
 ''also'' calculate the lateness the old way, the way which expects timing
 to be accurate. We compare the two lateness values, and if there is a too
 high difference (say, more than 1ms), we write a message to the syslog
 saying e.g. `MediaKit node abc is late, timing inaccuracy xyz us`. Since
 we always use the `queued_time` for the late notice, the number of syslog
 message will be small and bounded. But if a user asks "why is my latency
 high", the syslog gives the answer: timing is inaccurate, we don't have to
 search for a bug in MediaKit, the problem is elsewhere.

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

Other related posts: