[haiku-development] Re: Ideas related to the media_kit
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 17 Nov 2015 12:25:45 +0100
Hi Julian,
The ports vs semaphores thing can be postponed in therms of development.
I'm going to continue my work on the BMediaFilter as it's a preliminary
step in achieving the points we previously discussed. Eventually, this will
be useful as a study of what a media2_kit API will look too.
But i think i was still too much vague on the subject so i decided to talk
about the code I've worked today as an example of why i think ports are too
much non-deterministic.
You've written before that you think the ports are a problem, but I don't
see why that is.
For example, let's take
BBufferConsumer::HandleMessage::CONSUMER_BUFFER_RECEIVED. Assume we are
using a BMediaEventLooper or an equivalent implementation too.
If the BBuffer allocation fails, we will have to skip this buffer. I don't
understand why we need this local/remote instance mechanism, we could just
pass a struct in the message (or read it from an activation table). But at
this point, strange things may happen. Basing on current common
implementation, for example the consumer might be tracking buffers
increasing an internal fTime value, if the buffer is skipped then there
will be a drift of one buffer duration when the next buffer is received.
Now let's consider we received the buffer and we were able to allocate it's
local instance. Assume that due to something external we got scheduled late
so when the BufferReceived() is called we are late. The current
BMediaEventLooper will add the event in the queue and schedule it at it's
timestamp. Once the HandleMessage() end, the event is scheduled in
ControlLoop() and since it's timestamp is in the past the subsequent
HandleEvent is received.
At this point we will have a lateness value greater than 0, the API client
then should decide what to do. Actually as we know it will send a
LateNotice to the producer to notify it that we are receiving events late.
In the meantime the buffer is produced and this late notice will eventually
come to the producer. The producer will eventually increase it's latency
and try to handle the next buffer early in order to compensate the
scheduling.
The final thing is, where's the warranty that the producer hasn't already
scheduled other buffers so our late notice will take effect after n
buffers?
How can we avoid that the n buffers which the producer already scheduled
before we sent the LateNotice will not cause other notices itself making
things even complex to be solved? We may run into an ever-increase latency
by definition.
Where's the warranty that our LateNotice will get blocked, and possibly
block us from receiving the next buffers? Since the LateNotice is sent
through the same port which is used to read the BUFFER_RECEIVED message.
What are the advantages that the design I've proposed have?
The biggest one is that it's implicitly atomic. It doesn't matter what
happen at this cycle, we know that at the next cycle anything will be
considered (such as the buffer example of before). This includes for
example events. If we schedule an event at this cycle it will be executed
in the next.
On the other hand, we avoid the possibility of conflicting read/writes. If
the buffer was late at node X in the chain depending on the various
run_modes it can behave differently. It could be skipped and in this case
the chain returns immediately to the server. We could be in
B_INCREASE_LATENCY, then log what we need let the buffer flow through the
chain and when the media_server will evaluate the current status, it will
increase the latency for this chain.
Also, additionally, why we should receive the buffer then schedule it, then
handle it? Wasn't better if the media_server scheduled it to be executed at
some cycle without any complication? It's just put in the activation table,
at the right point.
--
Best Regards,
Dario
Other related posts:
