Subject: Re: [linux-audio-dev] Locking Midi to Audio
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Sat Aug 17 2002 - 13:30:19 EEST
> 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
This archive was generated by hypermail 2b28 : Sat Aug 17 2002 - 12:37:28 EEST