linuxaudio.org

--20cf303b442732ccc304b0dcf7ef

Content-Type: text/plain; charset=ISO-8859-1
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')
thanks

iain
--20cf303b442732ccc304b0dcf7ef

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
Further to the conversation about Python to C++ ( with many helpful re=

sponses, 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 som=

ething (osc I expect). So I'm ok with the fact that user input and requ=

ests for user interface updates may lag, as the queue is likely to be reall=

y busy sometimes. I'm imagining:

Engine thread, which owns all the data actually getting=

 played ( sequences, wave tables, mixer/synth/effect controls, the works )<=

/div>- 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:=A0 =A0- get message off input queue de=

scribing change to a data point ( sequence or sample data )=A0 =

=A0- updates data point

- loop by mystery number 2:=A0 - get message off 2nd UI que=

ue requesting the state of a data point=A0 - sends back a messag=

e with that data to the requesterdoneG=

UI thread

- keeps it's own copy of whatever data is pertinent to that partic=

ular gui at that point- sends a bunch of requests if user change=

s the view- sends messages data change requests according to use=

r actions=A0

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 message=

s 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 varia=

ble. Anyone have suggestions on that? Is the system clock accurate enough t=

o check the time and see how much a sample period is left and make some saf=

e 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.<=

/div>

suggestions =A0most welcome.=A0(including 'that des=

ign sucks and here's why')thanksiain
--20cf303b442732ccc304b0dcf7ef--