[RoarAudio] new notify API

Philipp Schafft lion at lion.leolix.org
Tue Sep 7 16:50:18 CEST 2010


flum,

I just added a new notify API to libroar. It is mostly for roard
internal use. However it can be used by any application.

Devels do not realy need to care about it at the moment but if you are
intested continue reading :)

The notify API is basicly something like UNIX signals just that they
work inner-process and that you can pass some basic data.

In order to use it you create a so called notify core. It is contains
all infos needed to route your notifys (like signals) to the callbacks
you register (like signal handlers).

You can generate any number of cores. To make things easy there is
support to add createa global core so you do not need to pass around the
core object in your code. you can use both, cores by objects and a
global core at the same time (like the application has a central core
and some plugins use own cores internaly).

after creation you normaly subscribe to events on it.
The subscribtion include a basic filter (event type, and some other
parameters) so you do not get useless events. You now subsribe your
callback with this filter. After that if any event is send to the core
which matchs your filter your callback is called.

you get back a handle of your subscribtion. you can ignore it (use it
only for error check (ret != NULL)) or use it for later unsubscribe.

If you send a notify you include some information so the callback knows
what happened:
      * some flags (see docs)
      * the event ID
      * the emitter (for RoarAudio this is a clientid, for other
        applications this is a user defined int)
      * the target and target type. (for RoarAudio the target is the ID
        of a object (for example a streamid) and target type is an OT
        (ROAR_OT_*), for other applications those are user defined ints)
      * two integer args which are event-defined. for example for a
        'stream changed state' event this is the old and new stream
        state.
      * a void pointer and a length for the pointer. meaning of this is
        up to the event type like with the two integers. Its to pass
        more data if needed (for example a meta data change may pass you
        the new data..)


To make it possible to subscribe groups of events without needing to do
a lot subscribtions with the same callback there is a feature called
'notify proxy'. The proxy gets all events and emits new (group) events
based on the event it got. You can simply subscribe to such a group
event and get all events of this group.

There is a proxy for RoarAudio provied in libroar. Applications my use
own proxy. Each core supports only one proxy but your application
defined proxy can of cause simply run other proxys like the provided
one.

Aout the speed:
I messured yesterday on my PIII @ 500MHz and found this basic rule how
long an emit takes (this includes jumping in callbacks and out, not
include any time spend in callbacks):
            57ns * (subscribes per event) * (subscribed events)
        t = ---------------------------------------------------
                MIN((number of lists), (subscribed events))
        
(number of lists) is a parameter you can set at core creation time. It's
currently limited to 2^n with n=0..10

with 1024 events subscribed by 1024 subscribers (1048576 total
subscribtions):
      * Need about 14 secs to do all the subscribes (~74807 subscribes
        per sec).
      * Need about 82 secs to do 1024 emits per event (1048576 emits)
        (~12781 emits per sec)

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.keep-cool.org/pipermail/roaraudio/attachments/20100907/083ebc7a/attachment.pgp>


More information about the RoarAudio mailing list