On Fri, 16 Aug 2002 09:40:01 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> none of this, alas, addresses the more fundamental question of how to
> do the timing correctly. without something like the hard-timer patch,
> its more or less impossible to do MIDI sequencing correctly under
> linux.
This is an idea I had some time ago and simply have not had the time to
explore.
Nowadays few people would want to do Midi without doing audio at the same
time. This potentially leads to a great simplification in the handling of
Midi.
Why not lock the Midi processing to the audio processing? If the buffer
sizes for the audio are small, say 128 samples or less at 48kHz sampling
rate then all Midi messages can be processed at that granularity without
impacting the Midi timing too much. Midi can then be read and written via
raw midi ports instead of /dev/sequencer style devices.
Main benefits :
1) With all the Midi processing being done with the audio, the two
can't fall out of sync without the whole system stalling.
2) It removes the need for a separate process for Midi which is
competeing against the audio thread for the CPU
3) Raw midi devices are far easier to interact with than /dev/sequencer
4) Once the RT Midi handling process is removed from the system, it
may be possible to reduce the buffer sizes still further.
I realise that some people are going to complain about this screwing up
Midi timing. Well with audio processing done in 128 sample blocks at
48kHz sampling rate, Midi is processed ever 2.666 milliseconds. At 64
sample blocks its 1.33 milliseconds which is real difficult to complain
about.
What do people think?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid)
+-----------------------------------------------------------+
"Two hands working can do more than a thousand clasped in prayer."
-- anonymous
