On the basis that 2 <superscript>(n>0)</superscript> heads are better than 0.875
[see 1], I'll offer another theory (which is also mine, but does not relate to
brontosauri). In messing about with where the lock is acquired in effect/midi
control processing, my main aim has been chasing a reduction of the midi
latency,
rather than addressing the xrun problem when processing takes too long.
In its original form, MasterAudio() simply holds the lock for the duration of
it's processing. That means that a midi event associated with the first sample
of
a period can't actually be applied until that period's audio is processed. It'll
be processed next period, so by the time it's actually heard, the worst case
midi
latency is 2 * period time. Not so good.
In the original form, controller/effects changes also hold the lock for the
duration
of their processing, and some of them take too long for the audio processing to
wait.
If there happens to be a bunch of them queued up during the last period of audio
generation, then their cumulative delay could quite likely be crippling.
Last week I had the notion that maybe the audio could be generated in 32 sample
blocks,
opening a window at the end of each block to allow midi event processing. Tied
in with
this is a serious restructure of the midi code, that so far only exists in my
'experimental' branch. In that I've borrowed some code and concepts from the
a2jmidid
code. Jack midi is sample accurate, in that every midi event comes with the
precise
sample count to which it belongs. Alsa doesn't have that, but it can be added
by the
app processing.
I have tried processing the audio in 32 sample blocks, and it works just fine.
That
leaves the question of how to handle mid events et all that take too long, and
result
in the jack process callback timing out.
Tell me when to stop, and I'll go back to just quietly futzing about.
cheers, Cal
[1] I figure a good 0.125 of my head is gone beyond redemption. Have I not
mentioned
the brain tumor? :-)
