High CPU usage on both fluidsynth and pulseaudio when no midi is being played.

[hurricane-src]

FluidSynth version

1.1.9

Current behavior

When I start FluidSynth in server mode with pulseaudio driver:

fluidsynth -i --server --audio-driver=pulseaudio -m alsa_seq -r 48000 /usr/share/sounds/sf2/FluidR3_GM.sf2

fluidsynth uses about 14% CPU
pulseaudio uses 42% CPU

No sound is played at the moment.

Expected behavior

I'm not sure about the expected usage when music is being played but I would expect 0% cpu usage when none is.

Steps to reproduce

I just run:

fluidsynth -i --server --audio-driver=pulseaudio -m alsa_seq -r 48000 /usr/share/sounds/sf2/FluidR3_GM.sf2

And look at the cpu usage using top

Other information

[derselbst]

Sorry, cant reproduce this. For me fluidsynth is barely at 3%, pulseaudio at 4%. Also I cant think of any relevant change that happened since 1.1.6. So currently cant give you any advice other than testing a different fluidsynth version (1.1.6, recent master,...) and different audio drivers.

[derselbst]

Note that even if no sound is played, fluidsynth is busy rendering audio (i.e. producing silence) and pushing it to pulseaudio.

[hurricane-src]

Out of curiosity, is there a reason silence is rendered ?
Maybe the high cpu usage was cpu related (I'm on a 2600K) .

[derselbst]

Currently there is no way of knowing when the synth is "clean", i.e. no sound playing, because even if there are no voices active, effects like reverb and chorus might still be playing. And speaking of effects, make sure you turn unneeded effects off (via commandline flags or fluid settings) to save CPU load.

[hurricane-src]

I've not read the implementation, obviously, but isn't there a kind of state machine ?
Surely must generate the waves from something.

For my specific issue, I've simply fixed it by adding midi hardware in the computer.

[derselbst]

No. Whenever something needs to happen, an API call to the synth must be made, eventually spawning voices that pull their data from the sample buffer(s). Another thread may come along at any time to render/mix the audio. Dont know what you're thinking of specifically, but states like on/off dont exist. And adding midi hardware fixed the high load of pulseaudio?

[hurricane-src]

So, if I understand correctly, broadly, there is one output channel open to pulseaudio and that means sending silence to it continuously until a event/note is finally sent. I currenlty use OpenAL for one of my apps, this makes me wonder what happens when I don't push buffers to be played. Maybe I've the same issue and never noticed it. (I'll look at this if I ever get the time.)

The midi hardware rendering does no go through pulseaudio (if there is a way, I've not searched for it as it was not required for my needs).

[derselbst]

So, if I understand correctly, broadly, there is one output channel open to pulseaudio and that means sending silence to it continuously until a event/note is finally sent.

A stereo output channel, yes.

[nudgegoonies]

I use alsa but i also experience 3-4 % CPU Load when idle. As far as i understood this thread, this is related to the effects. I havn't tried disabling then yet, but there really should be some mechanism to detect when no MIDI is played. I would expect 0 % when no note is played and no client is connected.

I tried it with chorus and reverb disabled. Then i experience 1 % Load while idle. Still too much for sleep modes on Laptops etc.

[derselbst]

Then i experience 1 % Load while idle. Still too much

Sounds like you like to start programs keeping them idle, giving them nothing to do and complain that they use CPU. I would probably agree if this were some commercial, well tested and engineered product. But the current implementation is simply not capable of that. The audio driver and the synth are completely unrelated components they dont know anything about each other. I dont see how to properly implement this. And imo it's more important that an audio driver reacts immediately when anything happens and not occasionally sleeps to keep CPU down. I may look for a more efficient handling under the hood, related to #197. However the only real solution for a 0% CPU usage would be killall -9 fluidsynth, sry.

[nudgegoonies]

Thanks for your explantation.

[mawe42]

One more note about this: it seems that PulseAudio is more sensitive to lower period-sizes than other sound drivers. FluidSynth uses a default period-size of 64 on Linux. So if you don't require low latency output from FluidSynth via PulseAudio (for example because you are simply listening to MIDI files and not playing a keyboard in real-time), then using a larger period-size will drastically decrease the CPU load. Use -z<periods> to specify the period size, maximum is 8192: fluidsynth ... -z8192.

[danielecr]

Then i experience 1 % Load while idle. Still too much

Sounds like you like to start programs keeping them idle, giving them nothing to do and complain that they use CPU. I would probably agree if this were some commercial, well tested and engineered product. But the current implementation is simply not capable of that. The audio driver and the synth are completely unrelated components they dont know anything about each other. I dont see how to properly implement this. And imo it's more important that an audio driver reacts immediately when anything happens and not occasionally sleeps to keep CPU down. I may look for a more efficient handling under the hood, related to #197. However the only real solution for a 0% CPU usage would be killall -9 fluidsynth, sry.

Sorry, but that is what is expected from every kind of server. I mean, let's take httpd server from Apache, it does not use CPU just because it is waiting for request.
This problem still exists, and really it is annoying, kill -9 is not a solution, I am sure there are other options, I mean at very least there is select(2) and poll(2) kind of staff to make the server act immediately, I did not looked at the code, I am almost sure that is not the problem, maybe there is an idle-message in protocol that can/should be ignored?

I see also in lsof a line like this

fluidsynt 12892 daniele   18u      REG                0,1     2312     1046 /memfd:pipewire-memfd:flags=0x0000000f,type=2,size=2312 (deleted)

it is ok?