Subject: Re: [linux-audio-dev] A "best" event delegation strategy?
From: Phil Kerr (philkerr_AT_elec.gla.ac.uk)
Date: Fri May 30 2003 - 16:59:36 EEST
Hi Lukas,
For the networking transportation you may want to have a look at IEEE
P1639, formerly known as DMIDI, and RTP-MIDI (aka MWPP).
Both provide a network transport framework for MIDI event transmission.
IEEE 1639 is layer 2, raw Ethernet, and RTP-MIDI is layer 3 based.
Regards
Phil
On Fri, 2003-05-30 at 14:44, Lukas Degener wrote:
> >
> >
> >
> >(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 - 17:11:08 EEST