[haiku-development] Re: Proposed changes to media_kit
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 12 Jul 2015 17:06:36 +0200
Hi,
As noted during the discussion (if I recall it correctly), is that this is
pretty much overkill, as there only ever are very few applications that
could quit to begin with.
The difference between 100 messages and 20 messages over day is really
completely negligible.
The _BigBrother thread is anyway a little bit different as it's exchanging
messages in a continuous basis and various decisions depends on it. I'm not
pointing out it only for optimization reasons. The hypothesis is that when
things goes wrong the port may fail, but the app hasn't quit really already
thus causing the team to be unregistered prematurely.
A second, and maybe better solution is to let the _BigBrother just check if
the team has really shutdown or is locked and see what he can do.
First of all, there is *nothing* wrong about sharing semaphores between
multiple teams (or threads -- that's not really much of a difference).
Nowadays, that's pretty much their only use case, as we support more light
weight constructs for single teams.
In facts jack2 does the same to synchronize clients, i've not deep know of
Haiku internals so i prefer to ask anyway.
The question is just what you will be using the semaphore for.
[...]
I guess you suggest that problems come from some erroneous semaphore usage
more than sharing them in teams.
What exactly is the problem you are trying to solve?
I'm trying to understand why in certain situations everything lock down
without any chance to recover from that. In Haiku there's something like an
upper bound with media nodes, if you keep opening audio files with
MediaPlayer even when there are 20/30 it continue to play. At some point
(hard to say when but happens always), you open just another file and all
the other MediaPlayer instances stop working. Once you kill MediaPlayer and
open another file all usually returns to work well. This has made me to
think about possible problems locking too many semaphores.
At least, if i cannot avoid it, i planned to add some code to avoid the
"straws that breaks the camel's back", but before doing that i've to find
the bottleneck.
I guess that depends on the API differences between the two classes; if
they can be used very similarly, deprecating it should be the way to go.
Yes, the main notable differences will be that BMediaPlayer is designed to
support just what the media_kit support, not limiting necessarily to
B_MEDIA_RAW_AUDIO or B_MEDIA_RAW_VIDEO.
Secondarily, BMediaPlayer will not automatically connect to the system
mixer, but will provide a Connect function to connect to any
BBufferConsumer, so the API client will ask for the system mixer to the
BMediaRoster and connect to it explicitly.
I'm fine with separating the R3 audio classes; are there any apps actually
using those still, though?
I think there's something very old media app such as 3dMix, and maybe BeIDE
needs too the symbols to run.
Best Regards,
Dario
--
« Nullius addictus iurare in verba magistri, quo me cumque rapit tempestas,
deferor hospes. »
Other related posts:
