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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-audio-dev@...>
Date: Thursday, November 3, 2011 - 11:30 pm

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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] timing the processing of queues between engine and ui ..., Iain Duncan, (Thu Nov 3, 11:30 pm)
Re: [LAD] timing the processing of queues between engine and..., Gabriel M. Beddingfield, (Mon Nov 7, 2:01 am)