On 19.08.2015 15:58, Dario Casalinuovo wrote:
From what i can see, the Be's released nodes expect that
the dequeue lateness...
If you have concrete pointers, feel free to post them. However...
The first example that comes to my mind is the calculus done in the
LoggingConsumer. It's ignoring lateness but do the same calculus i'm
doing in my implementation of BMediaEventLooper to check if it's late.
The same formula is showed more than one time in the bebook.
It's right, but still i can't see why we should have a scheduling
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.
Well at this point i would change the lateness parameter name to some
more clear name, such as enqueueLatency.
It also doesn't matter which component you increase, since the net
effect will be exactly the same (handling an event will start that
Let consider for simplicity that all nodes will have the same jitter in
such situations, such as X, then i'm observing that instead to increase
all nodes latency of an X value, the nodes can recover better if they
use some fraction of this, taking into account also other things.
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.
Well, not really. If we adjust the scheduling latency using the enqueue
lateness, then we can subtract this value and try to report only the
part needed for the late notice.
Sorry, this is all so vague that it's hard to say anything about it.
You imply that we deal with complex graphs.
Isn't the actual media_kit something supporting complex graphs? It can
theoretically have any number of nodes with any kind of N:N connections.
The fact that Haiku doesn't have applications using it extensively
doesn't mean that we shouldn't go in the direction that almost all
general purpose realtime processing systems are going. We have to
attract developers, otherwise what's the point of Haiku?
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.
Since the media_kit isn't so smart at such things compared to jack or
AudioUnits, i doubt we'll see any. Just remember how many companies such
as steinberg were interested in using BeOS to do DAW processing, but
resigned. Isn't it a reason to leave the media_kit as something for
Desktop purposes (MediaPlayer etc.) but provide an improved kit for