[LAD] memory allocation for the real time thread, opinions wanted

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-audio-dev@...>
Date: Saturday, February 25, 2012 - 10:26 pm

--e89a8f83a7d77da12604b9d15cc3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everyone, hoping to get opinions from gurus on here, who have been
*incredibly* helpful in getting my project to where its at. A million thank
yous!

Ok, the situation so far, which is working well:
- the app uses a generalized 'message' structure, all the different forms
of messages fit into this structure by having it act alike a union. ( ie, a
message always takes up the same amount of space, no matter the type )
- messages do not container pointers, in order that they be simple to send
and receive over network clients, hardware, etc
- there are ringbuffers between my audio thread and real time thread

What I'm tackling:
- I want to add the capability for messages to have deferred execution, so
they can be sent with a 'process at 4:3:1' kind of thing
- I think the best tradeoff for my app so far will be to use a hybrid of a
timeline array and a linked list. there will be coarse time values stored
by raw array indexing, speeding up lookup, and fine time values will be
stored in the messages themselves
- so, when the engine is processing deferred messages, it will go and check
timelineArray for all messages at bar 1:beat 1, which will be a linked list
of all the messages with start time between bar:1 beat 1 and bar 1: beat 2
( time resolution may change, this just for example
- then the engine iterates on every tick through that list of messages.
This way, iteration on every tick is limited to a reasonable sized linked
list and I can play with the cpu vs data storage equation by simply
changing the resolution of the time line array

Issues:
- I need to allocate memory for new linked list items in the realtime threa=
d
- the timeline array needs to be able to grow in the real time thread

Thoughts:
- I don't need to get it perfect *right now* but I need to be able to
change it to Really Good later
- I checked out some resources, like this one the Design Patterns for *Real=
*
-*Time* Computer *Music*
Systems
and the supercollider book chapter and see there are a lot of options
- I could pre-allocate a giant list of messages and pluck the data off that
list when I need to make a new one
- I could pre-allocate a block of memory and allocate off that
- I could allocate in the non-realtime thread and then pass memory over in
queues.

Would love to hear opinions on how others would solve these, including
tradeoffs of each.

thanks!
iain

--e89a8f83a7d77da12604b9d15cc3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everyone, hoping to get opinions from gurus on here, who have been *incr=
edibly* helpful in getting my project to where its at. A million thank yous=
!Ok, the situation so far, which is working well:
- the app uses a generalized 'message' structure, all the diff=
erent forms of messages fit into this structure by having it act alike a un=
ion. ( ie, a message always takes up the same amount of space, no matter th=
e type )
- messages do not container pointers, in order that they be simple to =
send and receive over network clients, hardware, etc- there are =
ringbuffers between my audio thread and real time thread
What I'm tackling:- I want to add the capability =
for messages to have deferred execution, so they can be sent with a 'pr=
ocess at 4:3:1' kind of thing- I think the best tradeoff for=
my app so far will be to use a hybrid of a timeline array and a linked lis=
t. there will be coarse time values stored by raw array indexing, speeding =
up lookup, and fine time values will be stored in the messages themselves
- so, when the engine is processing deferred messages, it will go and =
check timelineArray for all messages at bar 1:beat 1, which will be a linke=
d list of all the messages with start time between bar:1 beat 1 and bar 1: =
beat 2 ( time resolution may change, this just for example
- then the engine iterates on every tick through that list of messages=
. This way, iteration on every tick is limited to a reasonable sized linked=
list and I can play with the cpu vs data storage equation by simply changi=
ng the resolution of the time line array
Issues:- I need to allocate memory for new l=
inked list items in the realtime thread- the timeline array need=
s to be able to grow in the real time threadThoug=
hts:
- I don't need to get it perfect *right now* but I need to be able=
to change it to Really Good later- I checked out some resources=
, like this one the=A0De=
sign Patterns for Real-Time Computer Music Syste=
ms

and the supercollider book chapter and see there are a lot of options<=
/div>- I could pre-allocate a giant list of messages and pluck the dat=
a off that list when I need to make a new one- I could pre-alloc=
ate a block of memory and allocate off that
- I could allocate in the non-realtime thread and then pass memory ove=
r in queues.=A0Would love to hear opinions on how=
others would solve these, including tradeoffs of each.
thanks!iain

--e89a8f83a7d77da12604b9d15cc3--

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

Messages in current thread:
[LAD] memory allocation for the real time thread, opinions w..., Iain Duncan, (Sat Feb 25, 10:26 pm)