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

From: "jua" <trac@xxxxxxxxxxxx>
Date: Sat, 12 Oct 2013 22:02:16 -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):

 Replying to [comment:15 bonefish]:
 > A reasonable solution would be to add a `queued_time` field to
 `media_timed_event`, filled in when the event is added.

 I wonder whether saving the time of enqueue is really the right solution,
 considering BeOS did not have such a data field.

 Considering what was also said by bonefish:

 > We don't want something that works just because we have added enough
 work-arounds. In fact adding work-arounds usually makes it more
 complicated to find the actual problems.

 This rings very true and in the end, using `queued_time` is just that: a
 work-around. The actual problem are the "blackouts" happening at all,
 which is a bug in either the kernel or a driver.

 If code makes a call to `read_port_etc()` with timeout, it is reasonable
 to expect that it will wake up in time and not be delayed 5-8ms by a
 randomly positioned blackout. So if the kernel's timing works correctly as
 specified by the API and drivers do not misbehave, the original version by
 Marcus is correct in calculating the lateness after the dequeue in
 `BMediaLooper::ControlThread`. Without blackouts, simply nothing can
 happen to make the lateness wrong in that place.

 I suppose in Be's version of the MediaKit it was simply assumed that
 timing works correctly. After all, the BeBook e.g. makes very clear in the
 Device Drivers section, that a driver must ''never'' disable interrupts
 for more than 50 microseconds.

 So the question is: do we want to mask the problem of blackouts by adding
 `queued_time`, or intentionally go without it to make the problem visible?
 I'd root for the latter, but would very much like to hear more opinions on
 it.

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