Latency and Dropouts

Hello everyone,
I am new to this forum and also to the zynthian. I build my own Zynthian with a raspberry 4 + Hifiberry DAC+ ACD pro and overall it runs great and i am happy. Using it in our band rehearsal room to have some fun in between with all the available Synths, Drums, Effects and also the MOD UI.

Now to my problem. The latency of the Synthian in “normal” mode for me is just too much, especially if i use the keyboard to play some drums and record this on my external looper. Therefore i changed the samplerate in the Jackd Options (as explained here in the forum) to 128. Now the latency for me feels great also to play the drumsounds in time.
Now the problem is, that i am getting some audio dropuots (and an exclamation mark in the top right corner).
I was now thinking, if it is possible to change the audio options so, that the Zynthian only runs in mono and only uses one channel. In my head having stereo and 256 as samplerate should be the same as having only one channel and using 128 as a samplerate, or am i wrong here?

Here are my audio options from the Zynthian

Hifiberry DAC + ADC Pro
Jackd Options:
-P 70 -t 2000 -s -d alsa -d hw:sndrpihifiberry -S -r 44100 -p 128 -n 2 -X raw
Aubionotes Options:
-O complex -t 0.5 -s -88 -p yinfft -l 0.5

Can anyone help me with these parameters? Unfortunately i didn`t find any good explanations as what all of these parameters mean.

Thanks and greetings.

I’m pretty sure we would be capable of running most of engines at 128 without XRUNs…

  • What engines are you using for the drums?
  • With all of them you get the same XRUNs?

Regarding your question, i don’t think you can run the Hifiberry on mono mode.


Im using linux Sampler sfz/Drums Engine.
Guess i have to figure out what XRUNS means. Sorry, but i am new to this and dont understand most of this right now.
Thanks for the quick answer though.

1 Like

Linuxsampler stutters can be associated with slow memory cards and limited polyphony. The point is, linuxsampler does not load all sounds entirely into memory, but loads them as needed during execution. requires fast flash memory to work correctly, a simple class 10 memory microSD card is not enough.

Try using the fluidsynth engine, it uses sf2 sample format and a lot more polyphony…
fluidsynth loads all the samples of the instrument in use into RAM, and usually, problem does not arise with it.

1 Like

Seriously … we should work a little bit on improving the Linuxsampler build options and optimizing for RBPi4. Also, we could try other “engines” with SFZ support.

Until then, i think Fluidsynth is a better option if the more limited SF2 format is enough for the use-case.


1 Like

This is not a linuxsampler bug, it is a way to save your device’s RAM resources.

The essence of the technology is that only the initial fragments of all samples used in the tool are loaded and if the performer holds down the keys on the MIDI keyboard longer than the existing sample fragment, the missing part is loaded directly during the played.

This mechanism was once used by Gigasampler, Gigastudio, and is now used in Native Instruments Kontakt, Soundlib G-player, Steinberg Halion… this allows you to load tools that exceed the volume of your computer’s RAM…

Linuxsampler requires a high bandwidth SD card or USB flash drive to work correctly.

1 Like

Of course … but we can adjust the way it works. How much ram it will use, how much data will preload from every sample, how many voices , etc. Current binary is optimized for RBPi3 …

If someone wants to advance with the task:

We could adjust these parameters:

  • max-voices=21
  • max-streams=64
  • min-refill=4096
  • refill-streams=2
  • stream-max-refill=131072
  • stream-size=262144
  • subfragment-size=64
  • eg-min-release-time=0.001
  • eg-bottom=0.0025
  • max-pitch=2
  • preload-samples=65536

And perhaps others that currently are using default values. Of course, the only documentation is on the Linuxsampler’s source code … so i can guarantee a funny hack session!! :wink: