[haiku-commits] Re: haiku: hrev49508 - src/kits/media
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 7 Aug 2015 20:35:43 +0200
Hi Julian, sorry i don't have a lot of time to reply
It's not a speculation, it's a defintion. Sure, not from the BeBook, it
was formulated by me, based on the views expressed by bonefish in said bug
ticket.
We have a compatibility to respect right? I think BeOS supplied lateness in
the way i calculated it.
Staying on your definition of lateness literally, i may enqueue an event
at time X for performance time X+Y, but if i have a delay after X the
buffer isn't late? This is funny non-sense :-)
That is nonsense indeed, and it is not what I wrote at all.
That's why i asked for raw formulas.
We are talking about the control loop of BMediaEventLooper, so of course
what we discuss only applies to those. How non-BMediaEventLooper-nodes
implement lateness is their own business and not relevant here. As long as
those nodes fulfill the seamlessness constraint as well, everything will be
fine.
In the MediaKit it is always the consumer node who notifies the producer
node of lateness, you can read that up in the BeBook. The notification does
not happen in the BMediaEventLooper control loop itself, right, but the
control loop calculates the lateness value which the consumer should later
use for notification.
Obviously i know this. But it seems you didn't catch, if latency is handled
at another level why BMediaEventLooper should care of this? In the BeOS
implementation it wasn't doing nothing of this.
And of course BMediaEventLooper must decide who is late. It already does
that now, by either passing a positive value or a zero in the lateness
parameter of DispatchEvent().
No it is reporting the lateness of the current node to the underlying
level, but does nothing to decide who is late effectively.
For a buffer event, passing on a positive value means "the producer who
sent us this was late by this amount", passing zero means "the producer who
sent us this was on time".
Rather obvious, but this isn't deciding 'who' since the responsibility of
the current instance of BMediaEventLooper is only of the current node not
others.
As was written before (by others as well), the Media Kit should and can
handle such blackouts/delay situations.
Are you aware that those blackouts will be caused mostly by ports? They
aren't Zeus flashes from the heaven.
It's in my opinion one of its best features. However, it only works
properly when lateness is handled correctly.
But as said i don't understand at all your lateness formula, i can accept
that we use the queued time to handle better latency notices (that's why i
suggested to do it at low level) but not for the lateness.
I gave a detailed example of the problem. It is not necessary to have a
test-case in code-form to see what's broken.
I've asked for this because i have begun to work on the ControlLoop since i
had strange & increasing lateness in libjackcompat. This was a blocker to
continue the development of this app. My changes seems to fix those
problems. I think to don't use test-cases is not a serious approach on the
problem.
Then please re-read the example I gave. The situation in it is not handled
correctly by your code.
As said i'm not very convinced by all, but i'll research indeed.
--
Saluti,
Dario
« Nullius addictus iurare in verba magistri, quo me cumque rapit tempestas,
deferor hospes. »
Other related posts:
