[LAD] how to store deferred events in a real time audio app?

[Tim Goetze]

[Paul Davis]

>On Tue, Dec 20, 2011 at 8:24 AM, Tim Goetze <tim at quitte.de> wrote:
>
>> Alternatively, out-of-order queuing can be dealt with by sorting the
>> contents of the FIFO in the consuming thread (since the write position
>> only ever increases, sorting everything before it is safe).
>
>as long as the length of the FIFO is relatively small, this is true.
>sorting is rarely linear though, so you need to be careful if you want
>this to scale to absurdly large message queues :)

Yes, and fortunately commonly occurring events from MIDI-sourced 
tracks are relatively sparse.  If these events are only enqueued in 
bursts a handful of times per second the sorting overhead is quite 
small, and reduced further if sorting only occurs when the consuming 
thread detects write pointer movement on the FIFO.  (Since there's a 
certain contention for the track lock between recording, playback and 
editing, hard realtime access to the track contents seems all but out 
of the question anyway.)

>>  Multiple
>> writers can be supported locklessly by employing one FIFO per writing
>> thread (the consuming thread peeks at the contents of all FIFOs before
>> deciding which event to pop first).
>
>true, though this is more complex for the reader, and the writers are
>rarely under RT constraints which means that the serialization via a
>lock doesn't hurt anyone.

There'll be at least the realtime MIDI input thread, and then there 
are events generated from audio streams that have to be dispatched in 
a lockfree code path.  (Of course, none of this is much of a concern 
if you do all your realtime work in a jack audio processing callback.)

Tim