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

On Sat, Feb 25, 2012 at 2:25 PM, Iain Duncan <iainduncanlists@email-addr-hiddenwrote:

> 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
> thread
> - 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<http://www.google.ca/url?sa=t&rct=j&q=audio%20allocating%20memory%20in%20real%20time%20thread&source=web&cd=3&ved=0CDIQFjAC&url=http%3A%2F%2Fwww.cs.cmu.edu%2F%7Erbd%2Fdoc%2Ficmc2005workshop%2Freal-time-systems-concepts-design-patterns.pdf&ei=g1xJT66mEYvOiALDnN3oAQ&usg=AFQjCNET-FI8lrlYfnIBP39Dwr-GLDptrA&sig2=f5fUXFebwZ6MpOcF2tYJug&cad=rja>
> 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.
>
>
Also, any thoughts on 'good enough to start with' techniques welcome!

iain

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Feb 26 00:15:05 2012