midi synths and pipewire port inconsistency
Version, Distribution, Desktop Environment:
1:03.24, Arch, Gnome
Description of Problem:
I'm super old and play a lot of old people games. Before pipewire, a fluidsynth daemon would sit on midi port 128:0. Several applications e.g. wine actually hardcode this number. At some point, pipewire started taking that port with their own stuff (I don't know what it is), and fluidsynth got bumped to 130:0. Whatever, it's an extreme pita but I can go into each wine prefix playing some midi game and change the default. Well it's a bit crazy and I should have filed a bug then but I didn't because I didn't feel like it. Don't judge me! :)
Anyway maybe it has something to do with me recently replacing pulse with pipewire (I've managed to screw around in the config and get latency stupid low on my cheap usb headset, too. Awesome stuff), but I just noticed fluidsynth and pipewire jumping around on reboot. That leads to an untenable situation because I can't even rely on the ports not changing.
Right now, aconnect -l
gives this output:
client 0: 'System' [type=kernel]
0 'Timer '
Connecting To: 130:0
1 'Announce '
Connecting To: 15:0, 130:0
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 15: 'OSS sequencer' [type=kernel]
0 'Receiver '
Connected From: 0:1
client 130: 'PipeWire-System' [type=user,pid=1371]
0 'input '
Connected From: 0:1, 0:0
client 131: 'PipeWire-RT-Event' [type=user,pid=1371]
0 'input '
client 132: 'awe32' [type=user,pid=1356]
0 'awe32 '
But y'know. Sometimes it'll be 128 sometimes 130. Who knows what it will be on next reboot.
How Reproducible:
Pretty sure last three times I checked I got three different numbers.
Steps to Reproduce:
I have the following user service enabled:
[Unit]
Description=FluidSynth Daemon
After=sound.target
Requires=sound.target
[Service]
ExecStart=/usr/bin/fluidsynth -is -o shell.port=9800 -a $AUDIO_DRIVER $OTHER_OPTS -p awe32 /usr/local/share/Soundfonts/FatBoy-v0.790.sf2
EnvironmentFile=/etc/conf.d/fluidsynth
Nice=-10
[Install]
WantedBy=default.target
Then just check what's going on with aconnect -l
Expected Results:
AFAIK there's no way to configure fluidsynth to always use a certain port if it's available. I don't know if that's possible — I don't pretend to understand the underlying technology — but as a user I guess my expectation would be that system stuff like Pipewire to stay out of the way of user stuff, perhaps by using a very low or very high number.