thanks Dave, that's what I was looking for! Have you used this technique yourself? Do you have any suggestions on how that is done with non jack systems? And any open source code that uses that technique?

thanks so much.
iain

On Thu, Nov 3, 2011 at 5:42 PM, David Robillard <d@drobilla.net> wrote:
On Thu, 2011-11-03 at 16:29 -0700, Iain Duncan wrote:
> Further to the conversation about Python to C++ ( with many helpful
> responses, thanks everyone! ).
>
>
>
> 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 same 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:
>
>
> Engine thread, which owns all the data actually getting played
> ( sequences, wave tables, mixer/synth/effect controls, the works )
> - gets called once per sample by audio subsystem ( rtaudio at the
> moment )
> - does it's audio processing, sends out audio
> - loop by Magical Mystery Number 1:
>    - get message off input queue describing change to a data point
> ( sequence or sample data )
>    - updates data point
> - loop by mystery number 2:
>   - get message off 2nd UI queue requesting the state of a data point
>   - sends back a message with that data to the requester
> done
>
>
> GUI thread
> - keeps it's own copy of whatever data is pertinent to that particular
> gui at that point
> - sends a bunch of requests if user changes the view
> - sends messages data change requests according to user actions
>
>
> Here's my question, how do I determine the magical mystery numbers? I
> need to make sure engine callback is always done in time, no matter
> how many messages are in the queue, which could be very high if
> someone is dropping in a sample of audio. By making the data point
> messages very simple, I hope that I'll have a pretty good idea of how
> long one takes to process. It's just a lock-get-write to simple data
> structure. But how much audio processing has happened before that
> point will be variable. Anyone have suggestions on that? Is the system
> clock accurate enough to check the time and see how much a sample
> period is left and make some safe calculation with headroom left over
> there? It is totally ok for the queue and the inputs to lag if the
> audio number crunching goes through a spike.
>
>
> suggestions  most welcome. (including 'that design sucks and here's
> why')

Time stamp the events as they come in (e.g. with jack_frame_time()), and
aim to execute them at (time + block_size_in_frames).  This avoids
jitter, and keeps the rate that you execute them bounded by the rate
they come in.

You'll also probably want some kind of hard upper limit to ensure
realtimeyness when things get crazy.  That truly is a Magical Mystery
Number and will depend greatly on how expensive your events are.  Make
one up.

-dr