Re: [LAD] timing the processing of queues between engine and ui threads?

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')