[haiku-development] Proposed changes to media_kit

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 10 Jul 2015 22:14:10 +0200

Hello,
i have some plans to improve some parts of the media_kit, i'm going to list
what i plan to change starting from the immediate future. Part of it is
already in research state so that if someone have any concern it will be
pointed out before to do the work. My aim is in the long-term to bring the
media_kit in productive status.

* Move the Old* R3 files into a subdirectory. I think it's very important
to keep the src/kits/media directory clean, since they will be never edited
or developed i think it would be better to move them down in a appropriate
directory instead to stay with the 'active' files.

* Change the current media_server mechanism that use ping/pong messages to
watch for BMediaRosters.

It has been already discussed about modifying the registrar notifications
so that it's possible to watch only for a specific team. Once i do this,
i'll update my implementation of media services start/quit notifications to
take advantage of this (it is in a branch in github for any interested).

The idea is to just watch through the registrar for teams that registered a
BMediaRoster. Once a team is notified to quit, the media_server will run
the _TeamDied function instead to rely on the response of the port.

You can find the relevant code in media_server/AppManager::_BigBrother.

* Change BBufferGroup synchronization to don't use shared semaphores. The
actual implementation is using shared semaphores among multiple teams. The
bebook advise against that and it's discouraged.

https://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_Semaphores_Overview.html

(look at the Inter-application section)

The alternative solution proposed, is to run one or more thread (i guess
depending on the kind of concurrency) and lock local semaphores using
messages sent through a port. On a more deeper research, it results that
BeOS R5 headers had two private methods declared in BBuffer.
SetGroupOwnerPort and SetCurrentOwner, both with a port as argument, that
to me it seems to reflect exactly the lifecycle of a BBuffer, that is owned
by a certain group and is shared among some other, having always one
BBuffer instance per <group, buffer_id>. BBufferGroup also have a
SetOwnerPort method. So i propose to change BBufferGroup so that it will
run a thread, which will take care of doing the needed writes and reads to
claim and release a buffer at the previously mentioned ports. I'm already
doing some research about it, i have some reason to think that it will
solve various problems more and less important (deskbar locking?). I would
like to listen some opinion against it (if any).

* Implement BMediaPlayer and BMediaFilter then make BSoundPlayer deprecated
or alternatively make it a wrapper.

Best Regards,
Dario

Other related posts: