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

From: "bonefish" <trac@xxxxxxxxxxxx>
Date: Tue, 10 May 2011 10:13:21 -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 bonefish):

 Replying to [comment:16 Pete]:
 > Replying to [comment:15 bonefish]:
 > > Replying to [comment:13 Pete]:
 > I wonder if a separate `BTimeSource` is actually needed?  Although
 "RealTime" is nominally distinct from "system_time", they have been
 identical up to this point; is there any reason they ever ''would'' be
 different?  [If so, why?  I've never understood Be's reasoning here.]

 `system_time()` is called often and thus based on a cheap (i.e. taking few
 CPU cycles to read) clock. I believe Be's argument was that a more
 accurate and steady (but more expensive) clock might be available in the
 system and preferable for media use.

 > If there is ever such a possibility, it might be a good idea to add a
 "`RealTimeFromSystem(bigtime_t systime)`" method to `BTimeSource`, anyway.

 I suppose the other way around is of more interest, e.g. to compute wake-
 up times which normally need the system time.

 > If `queued_time` can just be from "`system_time()`", things would be
 simpler.

 `BTimeSource::RealTime()` is static anyway. I was rather thinking of
 setting `queued_time` to the performance time in case of a performance
 time queue, but I guess that doesn't even make that much sense, as one
 would need to use the real time to compute the lateness anyway. So never
 mind the `BTimeSource` idea.

 > > > I'm not exactly sure of the flow sequence here.  I think MixerInput
 is the next in line?
 > >
 > > No, that's just part of the mixer. The whole mixer is a single node.
 Next upstream you usually already have the audio producer.
 > What I was trying to figure out is what entity would detect and report
 lateness ''from'' the mixer's `MediaEventLooper`. I'd have thought this
 would have to happen before actual mixing of the streams.  (I'm afraid I'm
 completely lost looking at `MixerInput.cpp`.)

 I don't see why you'd want to compute another lateness value in the mixer.
 We compute the lateness of the buffer arrival which is used to adjust the
 previous node's latency and the next node will compute the lateness which
 is used to adjust our latency. Since there's only one latency value per
 node we can change, that does fully suffice.

 > > Apropos, latency change: I noticed that
 `BMediaEventLooper::SetEventLatency()` does not wake up the looper thread,
 which means that the event currently waited on will not be affected by the
 latency change.
 > Good point.  Does this require yet one more port signal code?  I don't
 see any "`CONSUMER_...`" code that looks appropriate.  Early on, when I
 thought I might need to wake up the looper myself, I wondered if there
 should be a generic "`WAKEUP`" code -- perhaps just 0.  Is this a bad
 idea?

 A separate code for waking up was what I was thinking of, too. Some prefix
 would be nice, though. Maybe `NODE_WAKE_UP` or `EVENT_LOOPER_WAKE_UP`.

 Another related issue I noticed is that `HandleInputBuffer()` should set
 `fLastLateNotification` too when it sends out a late notice. Unless the
 buffer is dropped completely, our downstream node might send us a late
 notice later and we'd otherwise adjust our own latency.

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