High CPU usage may impair real-time playback

[klerg]

FluidSynth version

2.4.3

Describe the bug

When playing Altitude.mid in Fluidsynth 2.4.3 with the default audio driver on some Windows 10 systems it will crackle at various points throughout playback of the MIDI.

Expected behavior

When playing Altitude.mid in Fluidsynth 2.4.3 with the default audio driver on some Windows 10 systems Fluidsynth should not crackle throughout playback of the MIDI.

Steps to reproduce

Download Altitude.mid below, open Fluidsynth 2.4.3, load GeneralUser-GS v1.47x.sf2 or GeneralUser-GS.sf2, play Altitude.mid and you may hear it crackle on some Windows 10 systems.

Additional context

It will also crackle with waveout driver, although it is a bit less, also this issue first appeared in FluidSynth 2.4.1 and continued in 2.4.2. AFAIK, cannot hear any crackling on FluidSynth 2.4.0. And turning on/off chorus or reverb has no effect on the crackling. One way to lower most crackling is to set audio buffers at 64, but no need for this in 2.4.0

ALTITUDE.zip

[derselbst]

Sry, but I not matter what audio driver I use, I cannot reproduce this on Windows. These problems are typically very closely bound to the soundcard and driver in use, the system load, and also to the various settings, like period-size and number of buffers that can be specified in fluidsynth, which makes it pretty much impossible to reproduce this or comprehend what's going on.

[klerg]

Well, even if you are not able to reproduce this issue it still exists on some Windows 10 systems. Given that the problem does not happen with Fluidsynth 2.4.0 I doubt the soundcard or driver is at fault here. Also, in 2.4.0 no need to mess with the settings, such as period-size or number of buffers so that pretty much rules out any of those as the cause, can the default value for audio buffers be 64 ?

[derselbst]

I cannot fix an issue that I cannot reproduce. Given the fact that no code changes have been made to the audio drivers between those version, and your vague description of the reproducibility of this issue ("you _may_ hear it crackle on _some_ Windows 10 systems) I am tempted to close this issue.

can the default value for audio buffers be 64 ?

No, because it would impose an unacceptable high latency for all users.

…

Message ID: ***@***.***>

[klerg]

I will give more info so you can reproduce the issue. That is good to know but this issue has nothing to do with the audio drivers and the cause most likely comes from either #1415, #1417 and/or #1424. all from 2.4.1. Yes, here is more detail, the crackling occurs on laptops with Realtek ALC3234 sound chip. I'm sure this will help keep the issue open, yes ?

Ok, I do notice some latency when the audio buffers are set to 64 on my end too

[derselbst]

You should observe the CPU utilization on those systems. Also play around with the -z parameter, which influences audio.period-size. Disabling reverb and chorus would lower CPU utilization, try this as well. And knowing the number of CPU cores, you can try to use multithreaded rendering with -o synth.cpu-cores

[klerg]

Sure, 2.4.0 uses much less CPU than 2.4.1/2/3 6% vs. 22%. This hardly has an effect on the crackling, and causes the MIDI to sound disjointed. I already disabled reverb and chorus but it still crackles and barely uses less CPU. It took some time to get this command, it needs =2 at the end, and that gives 7% CPU usage and no crackling. Is it safe to assume the high CPU is the cause of crackling, and any clue how to fix it ?

[derselbst]

The higher CPU usage could be an effect of #1444. I tried to mitigate that in #1469. Currently, I have no other ideas.

In the meantime, you're advised to use bigger audio buffers (-z) and potentially more of them (-c).

[klerg]

Yes, it seems like the high CPU use can be from #1444. I see too bad #1469 did not help.
I'm sure you will find more ideas soon.

I forgot to mention that -z also eats up more CPU cycles at upwards of 30% with spikes to 40%, -c gives more latency, only -o synth.cpu-cores helps but do not know why

[derselbst]

I forgot to mention that -z also eats up more CPU cycles at upwards of 30% with spikes to 40%, -c gives more latency

Which values did you fed to -z and -c resp?

Also: Which CPU are you using on the affected system(s)?

[klerg]

Well, I need to set -z to 2500 to stop crackling and -c at 8 to avoid high latency

Just 1 CPU core, but I'm not sure if the crackling comes from high CPU, because when I set -o synth.cpu.cores to 3, CPU use jumps to 30-40% but no crackles. Yet, -c 64 gets rid of almost all crackling, how to make sense of this ?

[derselbst]

Which CPU are you using on the affected system(s)? I need the exact model name.

[klerg]

Ok, sure the CPU is Intel Core i3-4010U, but how or why does that matter ?

[derselbst]

This is a dual core CPU, which explains that setting synth.cpu-cores to 2 or 3 works better than 1.

[klerg]

But when I set synth.cpu-cores to 2 or 3 it uses more CPU 30 to 40% than 1 which is in 20s how is that better ?