21 Dec
2011
21 Dec
'11
12:17 p.m.
[Paul Davis]
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
On Tue, Dec 20, 2011 at 8:24 AM, Tim Goetze
<tim(a)quitte.de> wrote:
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.)
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 :) 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.