Hi Ingo,
No, that is not correct. Since HandleEvent() is called immediately, the
callee can still get the dequeue time (respectively just a few cycles
later) and compute the lateness value you're computing.
From what i can see, the Be's released nodes expect that lateness is
the dequeue lateness...
If you have concrete pointers, feel free to post them. However...
latency if we don't use it in a meaningful way.
The thing is, the scheduling latency is not particularly useful, save for
guessing some initial total node latency. Afterward only the total node
latency is relevant. You can't really separate its components -- scheduling
and event latency -- anyway. E.g. heavy system load may cause the thread to
wake up slower, be preempted more often, and generally do computations more
slowly due to processor cache effects. It is a fairly useless exercise to
try and separate the two conceptual latency components.
It also doesn't matter which component you increase, since the net effect
will be exactly the same (handling an event will start that much earlier).
We can increase the scheduling latency, still using the enqueue_time,
but do more calculus on the late value so that we can recognize when
it's not an upstream fault.
Whatever you do, the point still stands: it makes most sense to pass the
arrival lateness to HandleEvent(). You certainly can do some additional
computations and increase the scheduling latency. However, that should also
be completely superfluous and probably even detrimental. If the arrival
lateness is passed to HandleEvent() the implementation is able to (and
should) determine whether it has to notify the producer that the buffer was
late and/or adjust its own latency when necessary (when handling the buffer
takes longer than expected). In the latter case adjusting the scheduling
latency automatically in BMediaEventLooper may cause the total node latency
to be adjusted twice as much in the end, unless you additional adjust the
lateness value to compensate.
No, it won't. As explained above, there is only one latency that matters:
The node's total latency. It is completely irrelevant whether the
scheduling or the event latency is increased, as only their sum is used
anyway (determining the time when to wake up for processing an event).
Instead using the proposed lateness meaning, we will just workaround the
problem without changing anything in the BMediaEventLooper flexibility
improvements we can have.
Using a useful lateness semantics will 1. fix the actual problem and 2. be
a fairly simple change. It will not require introducing additional API. The
"flexibility improvements" you mention are very vague. At least the
automatic scheduling adjustment part you mentioned won't improve anything.
It will just make things more complicated, since you'll have to
additionally manipulate the lateness value to avoid double adjustments of
the total node latency.
Sorry, this is all so vague that it's hard to say anything about it. You
imply that we deal with complex graphs.
However, the most complex thing I see is the audio mixer node, which has
multiple inputs and multiple outputs. Pretty much everything else is
basically just simple chains of nodes. I don't see what graph algorithms
you intend to use and for what (concrete) purpose.
