[haiku-commits] Re: haiku: hrev49508 - src/kits/media
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 17 Aug 2015 23:52:29 +0200
Hi Julian,
Using the enqueue time does not break compatibility though. When a node is
not late, it will still be not late when using the enqueue time. However,
when it is late, the lateness value is then more precise.
I think we should refine the whole approach so that it works at best. Even
if this will need to redesign or heavily extend the latency management of
BMediaNodes.
In the end, we don't know how BeOS implemented it (or at least, I don't).
As said, I spent a lot of time in research related to the bebook, Be
Newsletters and other Be Sample Code, such as the MotherNode and earlier
Big Bad Service Thread nodes implementations. I have a couple of references
that i can show that makes rather obvious it was the way BeOS worked. Not
100% sure but close enough.
But even if they didn't use the enqueue time... is that by itself a reason
to not use it?
The BeOS one worked well, i'm also wondering if it's a false positive
issue. Anyway at this point why not use the dequeue_time such as i'm doing
or both.
Using it makes the lateness handling implementation simply more resilient
to error cases. It doesn't make anything worse, but improves the results in
edge cases. Improvements over BeOS have been done in many other parts of
Haiku as well, so that's not unusual.
There are cases where similar problems occurs also using the enqueue_time,
since we are not considering how much time passed between enqueue and
dequeque. I find the "enqueque - event_time" lateness calculus just bad,
it's more logic to define it as "event_time - RealTime()". I think the
enqueue_time could still be used to make things much precise and avoid
problems but without creating wrong logic.
For example i'm considering about adding a new function such as
BMediaEventLooper::SuggestSchedulingLatency() to calculate the scheduling
latency using also the enqueue value.
I've done some code hacks to try to adjust the scheduling latency and the
nodes looked like more reactive and smooth than now. As said before the
nodes can work out with the different latency in various portions of the
code, and try to adjust things once the load change or when we have a
pathologic lateness. In this case the function mentioned will take care to
never increase the scheduling latency but use an average formula, taking
care of various limits such as the estimate_max_scheduling_latency value.
You must know who is late, or otherwise you won't know who should get the
lateness notice. A lateness value without any definition who it applies to
is not very useful.
I mean that itself the class doesn't handle this. In non-BMediaEventLooper
world, it's up to the node to decide who and when send a late notice. The
difference here is subtle, since BMediaEventLooper is doing the events
handling, the lateness value is provided to supply the low layer with a
value which otherwise would be impossible to have. In this sense,
BMediaEventLooper doesn't have responsibility in this regard. If there were
a way to avoid this, this wouldn't have added relying only on the low level
and absolve the BMediaEventLooper from this task.
I mean... you say that there is no decision of who is late. But what would
you do with the lateness value then?
It's up to the BBufferConsumer/BBufferProducer to decide this.
How do you propose would a node later on find out who was responsible for
lateness, who should get the late-notice, given only the value, without any
definition? It does not seem possible to me to use it meaningfully then.
Starting from the fact that blackouts shouldn't happen, and if it's
happening the problem is elsewhere, we may provide additional facilities so
that the underlying layer decide what to do.
This is a defect of R5 BMediaEventLooper, the fact that actually there's
not any way to get the node chain work with a less latency than
buffersize * nodes
Could you explain how you mean this? I don't see such a restriction.
It's an approximation but nodes are falsing some way the latency and go far
than needed really.
That's not something you can solve in the Media Kit alone.
That's obvious I think. But the main bottleneck here is the soft realtime
orientation of BMediaEventLooper.
Hard real-time is only possible if the operating system (i.e. kernel and
everything around it) supports it, which is not the case with Haiku.
I don't see anything that would prevent to run a different kind of
media_kit based on handling semaphores and areas instead of relying on
ports and areas.
Regards,
Dario
Other related posts:
