Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: ke syys 29 1999 - 18:54:39 EDT
On Wed, 29 Sep 1999, Paul Barton-Davis wrote:
> ><start of 2 cents>
>
> [ ... at least 2 pounds worth of comments elided ... ]
>
> Just a quick detail to mention, arising from something that just came
> up in Quasimodo.
>
> If you assume that one of the targets of communication is a thread
> running some of UI, and your further allow for the possibility that
> this might be a different thread than the one in which the
> communication originates, then you have to be *very* careful about
> designing the messaging system.
>
> As long as events which ultimately cause "messages" to be sent are
> caused by the UI, then there is no problem.
>
> However, I am just trying to get Quasimodo in shape to handle
> automation down the line, and this changes things
> substantially. Because X is not now, and probably never will be, truly
> thread safe, my working assumption is that only the thread that starts
> contact with the server can ever make contact with the server. The
> alternative is to use mutexes to guard access to the server, and this
> is an incredibly bad idea when one of the threads is a real-time audio
> engine, and the other is a UI which might take an unbounded amount of
> time before releasing the server mutex.
Perhaps you need an extra thread somewhere around here... Either just to fight
over the mutex with the GUI thread without getting the engine directl involved,
or as the only interface between the GUI and your application. Sounds either
"not too nice" or "far from trivial" to me, though.
> Why is this a problem ? Because it means that any "event" system that
> is based, explicitly or implicitly, on execution of some code within
> the same thread that raises the event, or that thinks it can escape
> without mutexes around event queues, will likely cause X errors at
> some point.
>
> If an automation object decides that its time to post a parameter
> change, and we want the UI object to notice it, it is *NOT ENOUGH* to
> either (1) put the event on a queue or (2) execute a callback to the
> UI code. In the case of (1), we have to grab the mutex around the
> queue, which may or may not be a good idea, depending on your timing
> constraints. In the case of (2), you have to implement a way to
> execute a callback in the UI thread, not the thread posting the event.
That would be some kind of IPC hack, like "local RPCs"... Possible, but I'm
afraid it doesn't solve much, as doing it from real time code will result in the
same timing problems as mutexes + the "RPC" overhead. I think reducing the
callback to an IPC message of some form should do... You might have to do some
select() hack or something in the GUI thread to take care of those messages.
> There are some workarounds to this, such as always running the
> automation code within the UI thread, and/or being very careful to
> hold queue-protecting mutexes for a very, very short time. But even
> so, you have to be careful. If the engine itself ever generates events
> that the UI needs to be notified of, you're back to square one.
Ok. But the events you send from a real time system to a non/soft real time
system may as well be degraded to the RT quality of the destination ASAP. That
is, queue them somewhere (using a pipe or whatever), so the higher quality RT
thread never has to block. That's the standard solution for RTLinux<->Linux
communication. It works well, and is very simple. Of course, if you want a more
efficient solution, use shared memory + semaphores, or something like that.
> I hope its obvious (to all who might need to care) why you want the UI
> to execute in a different thread than the engine of an audio system.
Well, unless the UI is a bunch of LEDs and some motorized faders, that is...
You probably want such a UI hard real time anyway, as long as it doesn't
jeopardize the stability of the engine. But that's quite different from what
we're discussing here.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST