[haiku-3rdparty-dev] Re: BMediaNodes communication with the extern world

  • From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
  • To: haiku-3rdparty-dev@xxxxxxxxxxxxx
  • Date: Mon, 14 Oct 2013 18:50:16 -0700

On Mon, Oct 14, 2013 at 06:19:25PM +0200, Dario Casalinuovo wrote:
> 
> I have with a my own project, the problem of making a media_node
> communicate with another thread. Imagine a producer/consumer node which
> have to receive data or media_events from the thread A dispatching them to
> the system mixer. Inversely it have to receive data from the mixer from
> some input and dispatch it to this thread. The latter could be done by
> calling a owner's method, more like it's already done in BSoundPlayer.
> 
> But the BeBook states "Note, however, that your application should never
> directly call any of your subclass' functions; instead, you should register
> the node with the media roster, and control it via BMediaRoster calls, just
> like any other node, by using the media_node that describes your node".
> 
> So...how can i schedule programmatically events to the node from the extern?
> I tried to find in the BMediaRoster a method related to some message
> passing between the app and the node, but it looks like there isn't any.
> I'm considering to create BLooper owned by the node and shared with the
> app, the looper will be used to notify that there's data available and will
> share some memory with the app. Is it correct to do it this way? If not how
> this is assumed to be done?

I'm afraid I'm having some difficulty understanding exactly what you
need to do, and what you think is preventing you from doing it.  Maybe
you could expand a bit.

If, though, you're reading that statement from the BeBook as meaning
that you can't call *any* methods in your derived node class, that's not
what it's trying to say.  [I don't think it's very clearly written!]  Any 
methods
that you've added yourself to the class can of course be used as you like.
The paragraph is referring to the MediaNode base methods that you
may have to implement to give it the desired behaviour.

And when you are working with, say, a BBufferConsumer, there are
certainly methods you will want to call yourself -- like SendBuffer().

There's probably no need for a separate looper, unless the messages
you're sending  are going to have to queue before being acted upon
or something.

Hope that's of some help.

        -- Pete --

Other related posts: