[haiku-commits] Re: haiku: hrev49508 - src/kits/media
- From: Sean Collins <smc.collins@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 05 Aug 2015 22:42:07 -0400
Julian Harnath wrote:
one additional note:
On 05.08.2015 13:50, Dario Casalinuovo wrote:
When the buffer is enqueued in B, A forgot it from a lot of time,
context switch happened already from a bit of time.
That is correct, it's about how you define the "enqueue", i.e. at what
point it really is enqueued. Ideally you'd generate the timestamp
atomically together with the port write. However, there is currently
no good way to do that without breaking compatibility, so doing it in
the TimedEventQueue seems to be the best choice.
The real underlying issue here, at least from my perspective, is that
you have the loop itself trimming the response of the loop. This is just
bad design, We would never do this in a deterministic environment like a
automotive ECU, and I would highly recommend against it here. If you
want to control the response to a buffer arrival departure and adjust
that timing, it should be done in a separate external PID loop which can
have it's own algorithm.
All calculations, measurements etc should be done against the external
clock, stored in a separate sub routine, and the algorithm to notify the
effected loop should be independent of the loop you are trying to
maintain control of.
buffer A is source, buffer B is Mixer, Buffer C is hardware emory bus
etc. All buffers always report timestamp to the watchdog, so the watch
dog may measure and adjust the packet stream to maintain optimal
Buffer A (buffer A send packet to buffer B and time stamp to watchdog)
Buffer B (receives Buffer A packet and notifys watchdog of current
time stamp, time stamp indicate buffer a is 4msec late)
Buffer C (buffer C notifys watchdog of timestamp )
watchdog compares timestamps and notifys buffer A to send timestamp 4
msec early, also notify Buffer B to send 4 msec early and Buffer C get
data early, which is OK because it will still play in order.
the watchdog in this case must always be external to the media kit, and
if the BEOS design does not work this way, it will perpetually give
and the most important part, buffer c must be aware of time stamp and
clock time, as must the other buffers. watchdog cannot adjust values
without timestamp data.
As far are the naming conventions go, I think this is a moot point, if
the media kit design is so flawed inherently, create a new private class
or a public one and just make a media server 2 and call it
BeProAudio_insertname_of_variable_here. the current media kit works with
the current applications and supports BeOS apps just fine.
I really want to grind this point home however, get the control of the
timing out of the loop that has the error tendency. IE break that
control into a separate loop with it's own control and algorithms. your
trying to drive the car, after it already made the turn you didn't want.
Other related posts: