> 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.
There might still be people who would like to use MIDI without audio. Also this makes MIDI dependant on a specific audio API/implementation. > 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. Audio/MIDI sync can be done just as well using UST/MSC. > 2) It removes the need for a separate process for Midi which is > competeing against the audio thread for the CPU This too should not be a problem if the system is well designed, i.e. all processes have suitable priorities depending on their rate and processing time. MIDI scheduling should run at a very high priority (higher than audio processing) and with a very short processing time. > 3) Raw midi devices are far easier to interact with than /dev/sequencer That may be, but that can be solved by different means. > 4) Once the RT Midi handling process is removed from the system, it > may be possible to reduce the buffer sizes still further. I'd rather have decent MIDI timing with a slightly higher audio latency. Has anyone tested how a well designed user-space MIDI scheduler thread impacts audio latency? > 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. Not all hardware may be running at 64 frames/period. Even so I would like to see MIDI jitter at around 500usec instead of 1.3msec or more. There are good reasons to have larger audio buffers when low latency is not required. --martijn
