Right, the documentation for plugin resampling
contains this warning:
A synchronous resampling ringbuffer such as this causes varying computational loads in the outer processing buffer. It is therefore not real-time safe.
Let me elaborate on this and address your questions:
1. "varying computational loads"
An example to illustrate this point:
Code: Select all
This configuration needs a Jack server running at 44.1kHz with block size 64 samples per channel. One block of audio from the sound card has a duration approximately 1.45 milliseconds. The resampling
plugin resamples the audio to sampling rate 16kHz and provides a blocks of 23 samples per channel to the loaded processing plugin, here gain
. One block of resampled audio as seen by the gain
plugin has therefore a duration of approximately 1.44 milliseconds.
Most of the time, whenever resampling
processes 1 block of audio at 44.1 kHz from the sound card, it will re-sample this to 1 block of audio at 16kHz and call gain
to process that one block. However, because the absolute duration of the audio blocks at 16kHz is slightly shorter than at 44.1kHz in this example, once in approximately every 100 times, it will need to have two audio blocks at 16kHz processed to catch up, and it will call the signal processing method of the plugin gain
2. "It is therefore not real-time safe"
One best practice when doing real-time audio processing is to design your signal processing algorithms in a way that the computational effort required to process one block of audio data is constant. E.g. the computational effort should not depend on the signal's content or on the current time of day. This best practice is violated by the resampling
plugin as described above.
Nevertheless, we still tend to use the resampling
plugin in our real-time configurations. You ask
3. Preparing openMHA configurations for real-time processing usage
Is this enough to assume that it can be used in real-time applications safely?
A real-time safe implementation of a plugin does not mean that you can always use it in real-time applications. It could still need more CPU for signal processing than your system can provide reliably. Similarly, usage of a plugin that violates one or more best practices of real-time signal processing algorithm design can still be possible in a real-time setup when you have enough CPU headroom.
The key to trusting your configuration to run in real-time lies in testing. Run your signal processing setup for extended periods of time in realistic conditions and watch for dropouts. qjackctl will display the dropouts that it detects, but whether you use Jack or not, you should also listen to your setup and watch out for dropouts subjectively.
Having all your signal processing algorithms obey real-time best practices will make this test easier and more trustworthy, not eliminate it. Behavior of resampling
is still relatively easy to test: The variations in computational load caused by resampling
jump back and forth between two possible conditions. This is better than e.g. writing to a file or printing an analysis to the terminal every 1000th block, in these conditions the computational load would jump between constant and unpredictable. Having resampling
in your real-time configuration will increase the ammount of testing that you will need to do.