[linux-audio-dev] A "best" event delegation strategy?

[Lukas Degener]

>
>
>
>(The "engine thread" here would usually be the real time audio 
>thread.)
>  
>
(...)

>You'll have to be more specific to get a more specific answer. :-)
>
>
>  
>
Ok, sorry, the scope of the whole proposal was somewhat ambigous, i'm 
afraid. :-)
I don't intend to work with audio stream, at least not right now. (there 
are dozens of apps that do this much more elegant than i would be ever 
able to do it)

The main focus is on midi events. And i also would rather like a push 
model for this. That is, the alsa sequencer client module listens on the 
input ports and creates events which are pushed through the network. The 
things happening within the individual modules will propably happen in 
constant time,  or O(n) respectively, if you send n events through them. 
So i don't expect performance problems from this side. The only thing i 
could imagine to have fatal impact on latency would be that a relevant 
thread is blocked / not awoken in time by the system. So i thought if i 
have a "master" thread runing with rt priority, which takes care of all 
the event delegation (i.e. via a global queue), i should not run into 
severe problems. For example: Any event source/subject, no matter which 
thread it runs on, delivers events to the global queue (which should, as 
you pointed out, be some kind of lock-free fifo). Every event is 
associated with the observer/listener it is to be delivered to. Another 
thread running with rt priority, reads the events from the queue and 
delivers them.
As a result, all event _processing_ would run on a single thread, and 
should happen in O(1).

I'd like to diregarded ui interaction for now. Anyway, events that 
orginate in the gui could be managed as any other event. Events that 
sould be send to the gui can be decoupled via another fifo.

As for the feedbacks: using a fifo in the way above should by itself 
introduce a minimal (but required) delay, and therfore make feedbacks 
controllable. (i.e. the loop is "flattned", no recursions.)

Ah, in the meantime, to other replies poped into my mailbox.

Kjetil:
yes i have tried pd some time ago, and was rather impressed by what it 
could do. I guess by now it is possible to cook coffee and get the girl 
next door laid with it. :-)
But i haven't ever looked at the code. And i imagine it to be rather 
complex. :-)

Paul:
Interestingly, what you describe as the thing ardour is slowly into, 
i.e. one RT thread to process moreless all events, is exactly what 
becomes more and more my favourite alternative. Mostly because it seems 
relatively easy to do, or rather i think i can imagine how this can be 
done. Two issues remain, nevertheless:

A) What happens if any future plugin for some reason does something more 
complex, let's say O(n^k) per event, would it still be possible to do 
this on the rt thread? Propably not. But anyway, how could one possibly 
guaranty rt processing of such a problem? Propably not at all?
B) How to implement a lock-free fifo? Or rather: is there some ready to 
use implementation of it?

Thanks for the replies, everyone.
Lukas