[haiku-development] Re: Ideas related to the media_kit
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 17 Nov 2015 18:20:41 +0100
Hi Julian,
What I've been trying to expose is that there's not anything in the
current implementation that can't be done in the cycle based one.
Instead there's a lot of undefined behavior in the node-centric one.
What undefined behaviour?
Taking the previous example, if the node B notify A that he is late, we
don't know really for which buffers this will take effect. The fact that we
can't precisely estabilish when something will happen, is really a serious
issue. RollNode is an example of that, but as said this situation happens
in different contexts. Another example might be if we disconnect/connect a
connection between two nodes, actually it's not well defined what will
happens. The current implementation do two ports write, one for the
connection and another for the disconnection. If the node is processing the
buffer (or cycle) n, how can i ensure that at the end of this process the
node will be disconnected and reconnected (atomically) so that at the next
buffer the node will use the right output? I think there are
infrastructural problems that are caused by this "undefined behavior".
By the way, I didn't claim that your approach can't work. I understand
that it would work as well. However, to completely change the way the Media
Kit works, I think we should have good reasons, a clear incentive. I don't
agree with the things you claim as being broken: those are partly
implementation issues (e.g. our current lateness calculation is still
broken -- see our last discussion regarding enqueue time); partly a few
design issues.
I think we should consider maintainability, too. I've fixed enough bugs
that i can say it's difficult to track all things out. And more the
functionalities will grow i expect the complexity to grow exponentially.
However, so far, I don't see anything which would make it necessary to
transition away from the node-centric approach. Also nothing which would
require "hacks" which you allude to.
I've also showed a lot of examples that show the need of something that can
work like a clock. If we were in an ideal world the media_kit would be
perfect, but unfortunately we should just try to let anomalies be excluded
by design.
All the things which you propose could be done as part of the nodes. E.g.
the "activation table log" could be interesting -- but that could also
simply be part of a buffer itself: every node would append its time-stamp
in the buffer as it's being processed.
Yes, but I'm right now of the opinion that this will not solve the problems
completely. Even if we do this by adding support to the actual BBufferGroup
class, the problems i mentioned previously like atomic-processing will be
still there. One limitation that the current media_kit will had is that we
can't ensure glitch free nodes inputs and outputs reconfiguration. What I'm
proposing should work like a pipeline, where we can ensure an isolation
between buffer processing and events handling.
It seems we won't reach agreement in this.
Discussions serve the purpose of finding it, I think i have shown enough
situations where the media_kit can have serious flaws in pratical use, and
probably defects that will never make it usable for professional use. Where
I understand that might be hard to accept that the foundation of the
media_kit is cause of more problems than what is supposed to solve.
--
Best Regards,
Dario
Other related posts:
