Subject: Re: [linux-audio-dev] A "best" event delegation strategy?
From: Lukas Degener (AFBLukas_AT_gmx.de)
Date: Fri May 30 2003 - 16:44:34 EEST
>
>
>
>(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
This archive was generated by hypermail 2b28 : Fri May 30 2003 - 16:52:41 EEST