In a way, this topic has already been addressed here, to which I believe there is unfortunately no update. Indirectly it has also been addressed in here.
All in all, I couldn’t find the steps needed to set the block size to a given value. My first question is: how can I do this? Also, by doing so, would the change stick after a software update?
My primary goal would be so set it to 64, instead of the default 128. It is already possible to set it to 256 via the advanced settings menu, so another question comes up: is it possible to set it to values less than 128 (64, 32, 16, etc…)? I am aware of the impact on CPU load.
I have a MOD Duo, but I believe it is the same topic for the Duo X and, in a near future, for the Dwarf,
You cannot set it as 64, i2s devices can’t cope with the hardware fast enough.
We give the option of 128 by default because most plugins work with this.
It is possible (internally) to change to something between 128 and 64, and audio still works fine, but quite a few plugins expect the buffer size to be a power of 2.
After remounting the file system as rw, I edited this file as follows:
# check if 256 frames option is enabled. Quick and dirty test: set to 96
if [ -f /data/using-256-frames ]; then
FRAMES=96
else
FRAMES=128
fi
# FIXME: sync mode with 128 frames causes xruns :(
if [ -f /data/jack-sync-mode ] && [ ! -f /data/using-256-frames ]; then
NUM_PERIODS="3"
else
# set to 3 just in case
NUM_PERIODS="3"
fi
However, the result is clearly still 256 samples per frame, as the CPU load is reduced, when the checkbox is checked. Funnily, when I power cycle the mod and go to the advanced menu, it shows “96 frames”, though the CPU load is reduced (hence 256). As soon as I tick the checkbox twice, it shows the correct “256 frames”, also with the CPU load reduced.
Any hints on what is missing or what I did wrong?
PS: is there an easy way to power cycle the MOD via ssh? The reboot command has a strange behavior, as the system seems to restart but the foot switches and display are frozen.
Well, you are editing things in a way that are not supported.
Instead of changing the initial value, you can also run in CLI jack_bufsize 96 after the system is live.
The screen has no idea that a reboot has taken place.
You can run hmi-reset to reboot the screen board controller. Then restart the mod-ui service to get things working again.
This is already clear to me Small update: I ran a more complex pedal board and there the CPU is indeed increased compared to 128 after a power cycle. So, the “96 frames” shown in the advanced setting seems correct. I will double check with a delay measurement later.
Changing the buffer size on the fly via jack_bufsize works like a charm. I was trying a few different values and was surprised that 512 doesn’t work, though it was not really my use case, as I was trying to get as low as possible.
I look for similar jack_* commands to configure the sync and number of periods on the fly, but none of them seemed obvious. What is the best way to tweak these values?
Audio buffer size:
audio buffer size is very much dependent on: 1) the configuration of your computer and 2) on the kind of audio device being used. Usually 256 samples is a good starting point but you might want to lower this setting to 128 samples or even to 64 samples if your audio hardware supports these settings. It is important to remember that too low of a setting can affect the overall performance of TH-U or the whole computer itself introducing clicking and crackling, commonly referred to as buffer dropouts.
It depends, if the audio codec and cpu is capable of that in your mod device.
Doable, perhaps stable with easy pedalboards.
This is what I would call a deep hack, though, but it is just my opinion.
Also, by doing so, would the change stick after a software update?