[LAD] timing the processing of queues between engine and ui threads?
iainduncanlists at gmail.com
Fri Nov 4 01:44:51 UTC 2011
> For my particular case, no drop outs is critical, and I really really want
> to be able to run multiple UIs on lots of cheap machines talking to the
> engine over something (osc I expect). So I'm ok with the fact that user
> input and requests for user interface updates may lag, as the queue is
> likely to be really busy sometimes. I'm imagining:
you're going to want at least 3 threads:
> 1) inside the engine, something to handle requests from a UI that
> cannot be done under RT constraints
> and route others that can into ...
> 2) the engine thread
> 3) some UI (not necessarily in the same process)
Thanks, can you elaborate on the first two? ( I appreciate the time,
understand if not ). Is thread 1 spawned by thread 2? Is the idea that the
engine thread can then start stuff that it allows to be interrupted but
still owns all the data for? And how would that be handled if that thread
is being handled by the audio subsystem and I'm just writing a callback
function that runs once a sample?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linux-audio-dev