[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.

Like this

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 efficiency.

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 trouble.

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: