latency/noise with real-time midi input?

[craigcomstock]

I am just starting to try out fluidsynth and love it. I am on alpine linux, using rtkit, fluidsynth version 2.2.4 and GeneralUser-v1.47.sf2 from the minuet package in alpine. I run with sudo since that seemed to be needed to get rtkit going.

I have a Roland UM-ONE usb to midi interface with a Rockband 3 Keytar wired directly (not wireless) and mostly it works great, but sometimes the notes get backed up and lag or some big white noise/distortions happen.

Just wondering if this is expected when playing lots of notes fast or if I'm missing something in setup.

Caveat: I am using a rather old laptop, IBM Thinkpad 240, Celeron at 298MHz, 1 core.

Thanks!

[craigcomstock]

I'll try on another more high powered laptop and see how it goes. :) But if there are any performance tips that'd be great.

[craigcomstock]

Ah. I am determined to reduce, reuse, recycle and if it doesn't work, reduce my expectations or rewrite the software to make it work. :)

Made most of those changes and it is awesome. I can smash all (24) keys all I want and it's solid.

Problem solved. Thanks again!

[mawe42]

Ah, and a more advanced optimization if you really need all performance you can get: compile FluidSynth yourself and configure it to use single floats instead of doubles. See https://github.com/FluidSynth/fluidsynth/wiki/BuildingWithCMake on how to compile FS yourself. And use cmake ... -Denable-floats=1 ... to compile it with single floats instead of doubles.

[craigcomstock]

Nice. I can easily do that. But as-is, I'm good. Will keep that in mind for when I start using an even less powered computer. ;)

[craigcomstock]

I marked my own response as an answer because that's all I could see. Thanks again @mawe42 for the answer(s) YOU gave. :)

[mawe42]

All good. Break a leg ;-)

[craigcomstock]

@mawe42 well, things were working great for me for quite a while. I re-installed fresh alpine 3.16 on my Lenovo Thinkpad X220 Tablet and things are lagging pretty bad even with the command I had working previously. Maybe I need to use jack?

The sound seems to lag about a second behind the midi notes sent from the keytar.

Is it maybe this "period size warning" that is the problem? I tried a few different values to no avail.

Also I found https://github.com/FluidSynth/fluidsynth/wiki/LowLatency and http://andrewdotni.ch/blog/2015/02/28/midi-synth-with-raspberry-p/ (which seems to have worked for them but has the period size warning in their output as well).

Here's my command:

fluidsynth -o audio.realtime-prio=99 -o synth.polyphony=10 -R0 -C0 -r 22050 -a alsa -m alsa_raw -o "midi.alsa.device=hw:1,0,0" -g 1.0 /usr/share/minuet/soundfonts/GeneralUser-v1.47.sf2

and the output when started:

ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
FluidSynth runtime version 2.2.7
Copyright (C) 2000-2022 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of Creative Technology Ltd.

fluidsynth: warning: Requested a period size of 64, got 470 instead
Type 'help' for help topics.

I tried polyphony=1 and that didn't help. If you think it might help I can try the compile option of single-floats instead of doubles.

The less powerful Thinkpad 240 was actually working great with that same command. I reinstalled that one also and fluidsynth is segfaulting, but I suspect that's due to using alpine edge (experimental/test) so I can retry there with an older alpine as well.

Thanks!

[craigcomstock]

I tried using the -d, --dump option and see the midi events coming in "real-time". I also removed the period size warning by adding -o audio.period-size=470 but that didn't seem to help the latency. Still about a second between midi event and sound. Hmm.

I also tried building from latest git source and then with cmake -Denable-floats=1 .. && make and still the same latency lag.

Anything else I can do to debug this? Some sort of internal bit in the code which shows the path between midi note and beginning of audio generation/sending to alsa driver?

[craigcomstock]

OK! I got it working! :) I payed attention to the warning message about period size and sent that in as -o audio.period-size=940 (it changed to 940 for some reason). I also added -c 2 (Number of audio buffers). I get a warning like

fluidsynth: warning: Requested 2 periods, got 3 instead

for whatever value I use, it always gets one more, but now the keyboard/midi notes and synth sound are in sync plenty enough to play some music!

Feel free to answer with some info about why this fixes it and close the discussion as answered! :) (again :p)

[craigcomstock]

I got things working again.

I payed attention to the warning message about period size and sent that in as -o audio.period-size=940 (it changed to 940 for some reason). I also added -c 2 (Number of audio buffers).

Thanks to various suggestions above my final command that works is

fluidsynth -c 2 -o synth.polyphony=10 -R0 -C0 -r 22050 -a alsa -m alsa_raw -o "midi.alsa.device=hw:1,0,0" -g 1.0 /usr/share/minuet/soundfonts/GeneralUser-v1.47.sf2