-1

Since switching from Kubuntu 20.04 to Ubuntu Studio 22.04 (both use KDE Plasma), I have had a strange cluster of issues. I'm wondering if they could be connected, but my main goal is to find a solution for issue #1. Anything else is icing on the cake.

I originally posted this as a much simpler question about issue #1, along with what I originally thought was the answer and a solution (which is still posted as my answer below... not sure if I should delete that).

The Issues

There are two strange things that are happening in my Ubuntu Studio install, but not always:

#1 - fluidsynth process sometimes starts automatically at boot. This really shouldn't happen. Fluidsynth is a synth and is the backend for QSynth and fluidsynth.dssi. This distro contains a lot of synths and there's no reason why this particular one should auto-start. Also, when fluidsynth starts in this way, I can't end the process in System Monitor - I have to do the ol' "killall -9 fluidsynth".

With the answer I initially posted below, I have since deleted the override file and reverted the WantedBy= variable back to multi-user.target. Neither the presence/absence of the override nor what I have that variable set to seem to make a difference. Neither causes the behaviour to always happen or to never happen.

#2 - sometimes, on boot, the cursor flashes a few times in the login box and then freezes and I can't log in, shut down, or restart. I have to go to tty and restart sddm.service and then everything works.

Possible Connections

There doesn't seem to be much consistency in what's happening. However, the two above phenomena seem connected. For example, just now, on booting, fluidsynth was auto-starting. It did this twice in a row. Then, on the third boot, I had the login-freeze issue. I restarted sddm.service, logged in, and fluidsynth did not autostart. Then I rebooted again, the login worked fine and fluidsynth didn't start. Everything seemed in order.

Another possible connection is that this might be more likely to happen after I've booted into Kubuntu on the same laptop, shut it down, and then booted into Ubuntu Studio. Before this latest round of auto-starts, I had just booted into Kubuntu. In Kubuntu, fluidsynth never auto-starts. The issue(s) also seem more likely to happen after certain system updates (as opposed to software updates).

Startup Programs

There is a fluidsynth.service in systemd. However, when I list in the terminal all systemd services, running or otherwise, including ones that are supposed to start at boot, fluidsynth doesn't show up in the lists. It also doesn't show up in the Ubuntu Studio settings for startup programs.

Other Possibly Relevant Info About My System

My distro uses a mix of ALSA, Pulseaudio, and Jack2 for sound. I can also see that there are some Pipewire processes in the System Monitor, but nothing "customer-facing" uses Pipewire (i.e. I don't, and can't, interact with it at all).

Info I've Tracked Down That Might Help With a Diagnosis

To try to get to the bottom of this (not really knowing what I'm doing, just following tips on the 'net), I found that the UID for fluidsynth process was 1278, so, in the terminal, tried the following (posted as a pic because I don't know how to paste the nesting)...

fluidsynth UID status

(The chart continued but I only copied to here to save space. Fludisynth doesn't connect to any of the remaining entries. Note that in the above, it is the default-GM soundfont that fluidsynth is loading. Fluidsynth needs a soundfont to be loaded before it can make any sounds. In that sf3 folder, there are several soundfont files, but for some reason this one is loading.

At the end of that output tree, this follows...)

fluidsynth UID status, ps

I also checked the system log for fluidsynth and got this...

system log

So with all this info, can anyone help me diagnose/solve my issue(s), or at least point me in the right direction?

Royan
  • 165
  • 2
  • 11

3 Answers3

1

This answer is an older post which I thought solved my issue, but later discovered that it doesn't. I will leave it here for now in case it can be in some way helpful. As it stands, I just removed Fluidsynth. Any proposed solutions I will try if I have the same issue when the next Ubuntu Studio LTS comes out.

I found an answer to my original question, as well as a solution (thanks in part to help from Muru in the comments).

The reason Fluidsynth was starting automatically at boot was that, unlike when I was using a Kubuntu 20.04 install with the Ubuntu Studio wrapper, this Ubuntu Studio 22.04 install for some reason has Fluidsynth set to do so.

In the file, /usr/lib/systemd/user/fluidsynth.service, under [Install], the WantedBy= variable was set to default.target, which triggers a start at boot. Kubuntu 20.04, on the other hand, had this set to multi-user.target and the process didn't auto-start.

I initially just changed this variable in the new install to match how it was set in Kubuntu, which did work, but Muru suggested that a future update could revert this back to the default. So, instead, I have done the following:

In the terminal...

systemctl edit --user fluidsynth.service

This creates a new folder in /home/user/.config/systemd/user called fluidsynth.service.d, and a new override file in this folder, and opens the latter for editing in the terminal. Under the line, "Anything between here and the comment below will become the new contents," I added...

[Install] 
WantedBy= 
WantedBy=multi-user.target

My text editor (which has been opened in the terminal) is Nano, so after adding the above three lines, I entered Ctrl+O to save the changes, accepted the file name offered to me, and then exited with Ctrl+X.

Now, this newly created override file in my /home folder does some kind of magic in the root folder which stops systemd from automatically starting fluidsynth at boot.

Royan
  • 165
  • 2
  • 11
0

My FluidSynth started in somehow weird state during a boot. Just after the boot, it competed somehow with PulseAudio and both took around 12% of CPU time each (according program top) and drained my battery swiftly and easily. FluidSynth service was not visible in systemctl, so I think it is a bug.

I got rid of Alsa plugin FluidSynth by renaming and rebooting afterwards:

sudo mv /usr/lib/systemd/user/fluidsynth.service /usr/lib/systemd/user/fluidsynth.service_nevermore

FluidSynth program is still working as a standalone application - it is what I need most.

I know that it is a dirty workabout. :-)

xerostomus
  • 1,060
0

I ran into fluidsynth starting automatically, and ran this to disable it:

sudo systemctl --global disable fluidsynth.service

I then found that all my Akai midi devices (or non-midi channel 1) input devices stopped working. They could be seen by these:

aseqdump-l 
amidi-l

But no events were coming through when played. In the end I had to re-enable fluidsynth to get all my midi devices working again. And I will have to live with fluidsynth always running apparently.

sudo systemctl --global disable fluidsynth.service

There's some pretty scary dependencies at work there...

Andrew Lyons
  • 1