linuxaudio.org

[Paul Davis]
>On Tue, Dec 20, 2011 at 8:24 AM, Tim Goetze  wrote:

quoted text
>

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

tracks are relatively sparse.  If these events are only enqueued in=20

bursts a handful of times per second the sorting overhead is quite=20

small, and reduced further if sorting only occurs when the consuming=20

thread detects write pointer movement on the FIFO.  (Since there's a=20

certain contention for the track lock between recording, playback and=20

editing, hard realtime access to the track contents seems all but out=20

of the question anyway.)
>> =A0Multiple

quoted text
>> 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=20

are events generated from audio streams that have to be dispatched in=20

a lockfree code path.  (Of course, none of this is much of a concern=20

if you do all your realtime work in a jack audio processing callback.)
Tim