Midi Controller stopped working after upgrading to Fedora 41

Ask Fedora
,
1

[SOLVED]

Hi all!
I have been succesfully using a Roland A-PRO midi controller with Fedora 39.
However, after recently upgrading my system to Fedora 41, the midi controller is not working anymore. The controller itself is fine and continues to work with MacOSX.

If i do aconnect -i it gives:

client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 24: ‘A-PRO’ [type=kernel,card=2]
0 'A-PRO MIDI ’
1 'A-PRO 1 ’
2 'A-PRO 2 ’

However aseqdump -p 24:0 shows no events coming through from the controller keys:

Waiting for data. Press Ctrl+C to end.
Source Event Ch Data

Any ideas how to fix this?

My pipewire is somehow broken with the upgrade, not sure if related to this issue. Typing pipewire gives the follwing error:

[E][05695.016261] mod.protocol-native | [module-protocol-: 784 lock_socket()] server 0x55d47c778100: unable to lock lockfile ‘/run/user/1000/pipewire-0.lock’: Resource temporarily unavailable (maybe another daemon is running)
[E][05695.018384] pw.conf | [ conf.c: 603 load_module()] 0x55d47c757110: could not load mandatory module “libpipewire-module-protocol-native”: Resource temporarily unavailable
[E][05695.019900] default | [ pipewire.c: 124 main()] failed to create context: Resource temporarily unavailable

Operating system: Fedora 41
Computer: Asus U38DT laptop
Vulkan drivers are experiencing some troubles after upgrade.
ALSA JACK status seems to be ‘off’.

Some system specification.

Audio:
Device-1: Advanced Micro Devices [AMD/ATI] Trinity HDMI Audio
driver: snd_hda_intel v: kernel bus-ID: 00:01.1
Device-2: Advanced Micro Devices [AMD] FCH Azalia vendor: ASUSTeK
driver: snd_hda_intel v: kernel bus-ID: 00:14.2
API: ALSA v: k6.12.11-200.fc41.x86_64 status: kernel-api
Server-1: JACK v: 1.9.22 status: off
Server-2: PipeWire v: 1.2.7 status: active
Machine:
Type: Laptop System: ASUSTeK product: U38DT v: 1.0
Mobo: ASUSTeK model: U38DT v: 1.0 serial:
UEFI: American Megatrends v: U38DT.204 Date: 2012
CPU:
Info: quad core model: AMD A8-4555M APU with Radeon HD Graphics bits: 64
type: MCP arch: Piledriver rev: 1 cache: L1: 192 KiB L2: 4 MiB

Any help is greatly appreciated! I posted about the same issue to fedoraforum too, will update both threads if any solution is found.

3

Hi again!
The problem was solved by the following combination of terminal commands:

sudo dnf upgrade --refresh
sudo dnf install midisport-firmware
sudo dnf install qjackctl
sudo dnf update pipewire
sudo dnf update pulseaudio
sudo dnf install pipewire-pulse --allowerasing
systemctl --user restart pipewire
aplaymidi -l

After these I found out that the midi controller events are coming through with:
aseqdump -p 24:1

For future troubleshooting I recommend using first aplaymidi -l to make sure the midi events are not already coming at some unexpected place.
It seems that what did the trick was to install pipewire-pulse with the option --allowerasing, which revealed that there was a conflicting package between pipewire and pulseaudio. The downside is that now sound while turning volume on, or other system event sounds such as alarm sounds have stopped working.

4

Trying to fix the system sounds, I notice pulseaudio now has some problems.
Its status gives at the moment “Unit pulseaudio.service could not be found.”
If I try to sudo dnf install pulseaudio, it gives:

Failed to resolve the transaction:
Problem: problem with installed package
  - installed package pipewire-pulseaudio-1.2.7-1.fc41.x86_64 conflicts with pulseaudio provided by pulseaudio-17.0-2.fc41.x86_64 from fedora
  - installed package pipewire-pulseaudio-1.2.7-1.fc41.x86_64 conflicts with pulseaudio-daemon provided by pulseaudio-17.0-2.fc41.x86_64 from fedora
  - package pipewire-pulseaudio-1.2.5-1.fc41.x86_64 from fedora conflicts with pulseaudio provided by pulseaudio-17.0-2.fc41.x86_64 from fedora
  - package pipewire-pulseaudio-1.2.5-1.fc41.x86_64 from fedora conflicts with pulseaudio-daemon provided by pulseaudio-17.0-2.fc41.x86_64 from fedora
  - package pulseaudio-17.0-2.fc41.x86_64 from fedora conflicts with pulseaudio-daemon provided by pipewire-pulseaudio-1.2.7-1.fc41.x86_64 from updates
  - conflicting requests
5

pipewire is the default and comes with the pulseaudio compatibility layer pipewire-
pulseaudio. You don’t need the pulseaudio server.
wireplumber should also be available and wpctl status should show you all active clients and sinks.

6

The system sound was finally resolved with a somewhat weird way.
First, I went to the normal Fedora settings, navigated to the sound settings, and found out that the Alert Sound option was saying “unknown”. I clicked on it, and system went crashing down, displaying something along the lines of “rfkill.service failed to …”

Then, after some time, system got itself back, and I was logged out. Logged back in, and proceeded to dconf-editor (you can get it with sudo dnf install dconf-editor ). There at " org / gnome / desktop / sound / " found out that theme name was __custom, switched that back to default, which is “freedesktop”. This made the basic alert sound work again. Then I also had to systemctl --user stop fluidsynth.service in terminal. Now also the volume adjusting system sound is working normally.

Everything seems to be in order now, so I will mark this thread as solved. But perhaps there’s something enough to cause worry for developers in that system crash that happened from the fedora sound settings interface.