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

From: "Pete" <trac@xxxxxxxxxxxx>
Date: Thu, 12 May 2011 23:42:40 -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:  1               |   Platform:  All
------------------------------+-----------------------

Comment (by Pete):

 Replying to [comment:22 bonefish]:
 > Replying to [comment:21 Pete]:
 > > Replying to [comment:20 bonefish]:
 > > > No, performance time is always in microseconds.
 > > >
 > > Are you sure (that that's what Be intended)?  The BeBook is either
 pretty explicit or pretty confused (in the BTimeSource chapter):
 > > ...[[BR]]
 > > They make a clear distinction there between microseconds and "time
 units".
 >
 > I'm too lazy to search whether "time units" is explained somewhere. I'd
 simply guess they wanted to point out that 1 performance time unit does
 not exactly equal 1 real time microsecond (due to a possible drift).
 Well I decided not to be lazy (:-)) and did a little more digging.
 I think it's quite clear what Be intended...

 In '''PublishTime()''':

   " drift indicates the value which indicates the rate at which the
 performance time changes compared to real time.

   The drift value makes it possible to interpolate intermediate values.
 For instance, if  playback of a video source is progressing at normal
 speed, the drift value would be 1.0,  indicating that performance time and
 real time progress at the same rate.

   However, if the movie is playing at half-speed, drift would be 0.5, so
 that for every one unit of real time that passes, only a half-unit of
 performance time would pass. This information is used to compute times
 without having to query the time source each time an update must occur."


 In '''SnoozeUntil()''':

  "Because performanceTime is specified in performance time, and
 withLatency is specified in real time, you can't just subtract withLatency
 microseconds from performanceTime and snooze until that time, because
 performanceTime may be passing at a rate faster than or slower than real
 time (if, for example, the time source is running at double-speed)."


 >
 > At any event a performance time unit must denote some fixed length of
 time. It cannot be some format dependent value (e.g. 1/44100s) as you
 suggested, since the format may be different at the beginning and the end
 of the media node chain (e.g. 44.1kHz CD player and 96kHz sound card), but
 still both ends must use the same time source.
 My interpretation is that all nodes in a chain would use the same time
 source, but the basic rate can be chosen to suit a need (which might be
 nothing like the usual audio or video chain, if you wanted, I guess).

 > Also, a good indicator is that `bigtime_t` is used to store performance
 time values, which is quite consistently only used for microsecond values.
 It would have to be 64-bit, and I suppose they just didn't think a
 separate type was justified.

 Would be nice if we could collar Jon Watte and ask what he ''really''
 meant (:-)), but in the meantime I'm going with my interpretation!

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