FluidSynth beim boot per script starten

Kubuntu 24.04, kernel-version 6.8.0-110-generic (64-bit)

Hallo zusammen!

Ich habe da eine mutmaßliche Anfängerfrage: ich möchte FluidSynth zur Wiedergabe von MIDI nutzen, und diesen beim boot automatisch starten.

FluidSynth an sich funktioniert wenn ich ihn per Terminal starte. ✅️

Für den Autostart habe ich dann erstmal eine config erstellt:

set audio.driver pulseaudio
set audio.period-size 64
set audio.periods 16
set audio.realtime-prio 60
#set audio.pulseaudio.server
set midi.driver alsa_seq
set midi.realtime-prio 60
set midi.alsa_seq.id bumfluid
set midi.autoconnect True
set synth.default-soundfont /usr/share/sounds/sf2/FluidR3_GM.sf2

Die liegt in meinem Home directory /home/meinuser/.fluidsynth

Wenn ich jetzt FluidSynth über den Terminal mit fluidsynth -f /home/meinuser/.fluidsynth aufrufe, gibt es zwar eine Fehlermeldung bezgl. high-priority, aber die hat nichts mit dem Problem zu tun. Prinzipiell klappt das, FluidSynth taucht unter qpwgraph auf und gibt Töne von sich ✅️

Ansatz 1: Also habe ich genau diesen Befehl in die crontab eingetragen. Das klappt aber nicht ❌️

Ansatz 2: Gut dachte ich, geht vielleicht nicht so direkt. Also habe ich das Script home/meinuser/.bin/fluidsynth-start.sh geschrieben:

 #!/bin/sh

/usr/bin/fluidsynth -f /home/meinuser/.fluidsynth

um das dann über die crontab zu starten:

@reboot /home/meinuser/.bin/fluidsynth-start.sh; touch /home/meinuser/_cron_ran_fluidsynth.txt

Aber das klappt auch nicht - die .txt Datei wird zwar angelegt, aber der Dienst wird nicht gestartet ❌️

Ansatz 3: Dann dachte ich, das evtl. crontab der falsche Weg ist, und habe versucht, das Skript in den KDE Systemeinstellungen als Anmeldungs-Skript zu starten. Funktioniert auch nicht ❌️

ABER: obwohl ich von bash nahezu null Ahnung habe, scheine ich in dieser einen Zeile keinen Fehler gemacht zu haben, denn wenn ich das Skript manuell über den Terminal starte, dann wird FluidSynth korrekt gestartet ❔️

So, und an diesem Punkt sind meine bescheidenen Kenntnisse am Ende und ich hoffe, dass jetzt irgendjemand sagt: "Ja, das KANN ja so auch gar nicht gehen, weil ..." 😉

Moin und danke für die Antwort.

Quote from gint-o-nix

Was hast du im Ansatz 3 genau gemacht?

Ohne es zu wissen, fast genau das was Du vorgeschlagen hast, allerdings über die KDE-Systemsteuerung, genauer gesagt über den dort befindlichen Button "+ Anmelde-Skript hinzufügen". Das hat auch insofern funktioniert, als dass dadurch sowohl der folgende Eintrag ...

... als auch eine .desktop Datei unter ~/.config/autostart erstellt wurde:

Heute, habe ich dann diese Datei mit dem validate Befehl geprüft, den ich auf der Seite gefunden habe, die Du mir verlinkt hattest.

Die vier Warnungen klingen für mich erstmal nicht kritisch. Dafür spricht auch, dass wenn ich diese .desktop Datei per Doppelklick starte, das Skript aufgerufen und FlluidSynth gestartet wird. Der Inhalt scheint also in Ordnung zu sein und sieht so aus:

Da diese Datei von der KDE-Systemsteuerung erzeugt wurde, dachte ich, dass dabei vielleicht ein Fehler passiert ist und habe die Exec-Zeile so geändert wie Du es geschrieben hattest, also:

Gleiches Ergebnis: führe ich die .desktop-Datei per Doppelklick aus, wird das Skript aufgerufen und FluidSynth gestartet, aber beim Boot funktioniert es nicht. Was sich allerdings ändert ist der Eintrag in der Systemsteuerung:

Dort hat sich die Befehlszeile entsprechend geändert (gut) und am Ende des Skript-Namens ist ein Anführungszeichen aufgetaucht...eines und nur am Ende. Das sieht gefühlsmäßig eher komisch bis falsch aus, aber wie gesagt: auch mit dieser Anpassung funktioniert die Datei wenn ich sie manuell aufrufe.

Nur mal nebenbei: generell funktioniert die autostart-Funktion auf meinem System, denn die anderen drei Programme (Caffeine, keepassxc und qpwgraph) werden beim boot brav gestartet.

Als letztes habe ich noch versucht, die Skript-Datei zu umgehen, um diese als Fehlerquelle auszuschließen. Also habe ich den Aufruf für FluidSynth direkt in die .desktop Datei geschrieben:

Auch hier wieder das gleiche Ergebnis: manuell per Doppelklick funktioniert es, beim boot allerdings nicht.

So weitere Tests haben noch folgendes ergeben:

Ich habe als Kontrolle eine .desktop-Datei für ein x-beliebeiges Programm (KSudoku) angelegt - läuft!

Dabei war mir das von KDE eingefügte Schlüsselwort X-KDE-AutostartScript=true aufgefallen. Das scheint aber nut dafür zu sorgen, wo der EIntrag in der Systemsteuerung angezeigt wird. Schmeiße ich diesen Eintrag raus, funktioniert es immer noch wird aber nun unter Programme angezeigt

Dann hatte ich noch gelesen, das man den Schlüssel StartupNotify im Zweifel besser weglassen soll. Habe ich gemacht, hat aber nichts geändert.

Quote from gint-o-nix

Man schreibt ja nicht immer ganz druckreif. Ich wollte heute noch ein PS darunter setzen, dass ggf. eine Verzögerung (delay) eingetragen werden muss (im bereits verlinkten Autostart-Artikel der letzte Absatz).

Danke Dir, das habe ich eben ausprobiert, leider wiederum nicht mit dem erhofften Erfolg. Folgende Beobachtungen:

• Der sleep Befehl funktioniert prinzipiell, das habe ich mit der oben erwähnten KSudoku.desktop erfolgreich getestet.
• Mit FluidSynth klappt es aber nicht, weder per Skript noch per "direktem" Aufruf in der .desktop
• Dann habe ich den sleep Befehl vor den Aufruf des Skripts gepackt und das Skript so geändert, dass beide Programme gestartet werden:

Exec=sh -c "sleep 15; /home/meinuser/.bin/fluidsynth-start.sh"

und

#!/bin/sh
/usr/games/ksudoku
/usr/bin/fluidsynth -f /home/meinuser/.fluidsynth

Das führt dazu, dass 15 s nach Anmeldung KSudoku gestartet wird, und nachdem ich das geschlossen habe wird dann FluidSynth gestartet 😳

Also vertausche ich die beiden Zeilen:

#!/bin/sh
/usr/bin/fluidsynth -f /home/meinuser/.fluidsynth
/usr/games/ksudoku

und es passiert... nichts! Weder FluidSynth noch KSudoku werden gestartet 🤯

Mein Gefühl (!!) sagt mir, dass es keine prinzipielle Fehlbedienung meinerseits ist, sondern ein FluidSynth-spezifisches Problem aber dazu passt dann wiederum nicht, dass es klappt, nachdem KSudoku gestartet und dann geschlossen wird. Ich hätte noch ne Idee für einen Test, aber dazu bräuchte ich leichte Hilfestellung:

Wie müsste ich das Skript ändern, damit zuerst KSudoku (oder irgendein anderer Alibi-Prozess) gestartet und dann per Skript geschlossen wird?

#!/bin/sh
/usr/games/ksudoku
# Hier muss der Befehl zum Schließen des eben geöffneten KSudoku rein
/usr/bin/fluidsynth -f /home/meinuser/.fluidsynth

Damit möchte ich das manuelle Schließen simulieren. Oder ist das nicht so trivial, da man die PID des KSudoku Prozesse nicht kennt?

UPDATE:

Ich habe gerade noch mal einen Test mit 30 s delay gemacht. Dabei konnte ich über qpwgraph beobachten, dass FluidSynth kurz gestartet und dann sofort wieder geschlossen wird. Hilft mir nicht weiter, aber ist denke ich wichtig.

Quote from gint-o-nix

Dazu einfach ein „ &“ ans Ende der Zeile.

Ich dachte mir schon, dass es kompliziert würde.... danke sehr 😄 Aber es ändert leider nichts:

Starte ich das Skript manuell per Doppelklick, werden beide Programm zeitgleich gestartet.

Starte ich das Skript automatisch per .desktop Datei wird nur Ksudoku gestartet aber nicht FluidSynth.

Dann habe ich das Delay mal auf 60 s hochgesetzt um auszuschließen, das FluidSynth von einem Dienst/Prozess abhängt, der extra lange braucht. Das ändert aber auch nichts. Und wenn ich unmittelbar nach dem 60 s verzögerten Start von Ksudoku das Skript per Doppelklick starte, funktioniert es wieder. Also scheint alles geladen zu sein, was FluidSynth benötigt.

Ich bin mehr und mehr am Ende meiner Ideen, außer der eher trivialen Erkenntnis, dass es wohl irgendein spezifisches FluidSynth Problem sein wird....

Ich bin kein Linux-Experte, aber kann das was mit dem user zu tun haben? Also dass das Skript wenn ich es manuell starte von mir ausgeführt wird und beim autostart vom system? Das wäre das einzige was mir gerade noch einfallen würde....

Will ich nicht, also zumindest nicht bewusst. Das wollte ich eigentlich mit meiner letzten Frage ausdrücken, dass ich nicht weiß, als welcher Benutzer FluidSynth gestartet wird, wenn ich es über diesen Weg aufrufe. Ein Aufruf als normaler user würde mir völlig reichen

Also, das anonymisieren von Benutzernamen, kenne ich aus anderen Foren und der Paranoiker in mir betrachtet das eigentlich als "guten Stil".... sorry, falls das in diesem Zusammenhang für Verwirrung sorgt. Wird das hier anders gehandhabt?

Quote from gint-o-nix

Drahtbuerste, wir reden doch von /home/meinuser/.config/autostart?

Ja ganz genau, es geht um meinen Benutzer mit dem ich mich anmelde.

Quote from gint-o-nix

Außer: Muss denn unbedingt über fluidsynth bei der Anmeldung abgespielt werden?

Quote from Gerbil

Soll fluidsynth iergendwie als Deamon im Hintergrund laufen und wie schickst du dem Programm dann die Midi Daten?

Achtung jetzt redet der Blinde (ich) von der Farbe 😉

FluidSynth ist quasi ein Nachfolger von timidity (falls das jemandem was sagt), der aber im Prinzip dasselbe macht.

Beide stellen einen Dienst zur Verfügung mit dem nicht nur MIDI-Dateien abgespielt werden können, sondern der auch als Ausgabe für Programme dient, die ihren Sound als MIDI-Stream ausgeben. Das sind diverse Musik-Programme z.B. PowerTab. Derartige Programme brauchen einen MIDI-Synthesizer (im Sinne von Klangerzeugung). Diesen könnte man natürlich auch jedesmal manuell vor dem Start der eigentlichen Anwendung starten, oder den Aufruf in die jeweiligen Programmstarter einbauen, aber so richtig fluffig finde ich das nicht. Und da dieser dieser Dienst keine wirklichen Ressourcen frisst, würde ich den gerne bei der Anmeldung starten wollen (völlig richtiger Hinweis von Gerbildass ich dazu nicht neu starten muss).

Die Zuweisung, welche Software ihren MIDI-Stream an FluidSynth sendet, erfolgt dann mittels PipeWire, also über eine Konfigurationsdatei bzw. mit einem der GUI-Tools, die es dafür gibt (qpwgraph). Das sieht dann im Erfolgsfall so aus:

Eine WINE-Anwendung (Power Tab) sendet ihren MIDI-Stream (magenta) an FluidSynth. Der Audio-Output (grün) von FluidSynth wird dann an eine Soundkarte geroutet (hier das Unitek Y247A) und ist damit hörbar. Wenn die WINE-Anwendung keine Daten mehr sendet (Pause) oder geschlossen wird, läuft FluidSynth weiter und wartet auf den nächsten MIDI-Stream.

Quote from Gerbil

Wenn du das willst musst du in deinem .desktop File ein Terminal aufrufen mit dem Parameter, das fluidsynth aufzurufen.

Ganz genau! Das ist der Plan und das config File, das ich ganz oben erwähnt habe und mit der Option -f einbinde. Das funktioniert auch (manuell) alles ganz wunderbar.

Quote from gint-o-nix

Wenn das Skript an sich funktioniert, der Autostart ksudoku zeigt, aber kein Ton, dann bin mit meinem Latein am Ende.

Genau so geht es mir auch 😉

Quote from Gerbil

Ja, hab offensichtlich was falsch verstanden wegen der crontab Geschichte am Anfang und der Beschreibung, es beim Booten starten zu wollen

Sorry, wenn ich damit Verwirrung gestiftet habe. Das mit crontab hatte ich aufgrund dieses Threads versucht:

NAS mounten wie Passwort speichern

Da das bei mir bisher zu funktionieren scheint, dachte ich, über diesen Weg mein FluidSynth Problem elegant lösen zu können - daher crontab. Und bei den Begriffen booten und anmelden war ich einfach schluderig, bzw. habe erst spät geschnallt, dass ich eben nicht neu booten muss.

Dat löpt.... wie geil!!!! 😁👍️👍️👍️

Danke an Euch alle, aber besonders an Gerbil

Zu meiner sehr bescheidenen Ehrenrettung sei gesagt: es ist nicht so, dass ich mich nicht eingelesen hätte. Die imho umfangreichste Seite habe ich im archlinux wiki gefunden, und da wird unter der Beschreibung des Daemon-Modes nichts von dem -s Flag geschrieben: https://wiki.archlinux.org/title/FluidSynth#Daemon_mode

Klar, jetzt denke ich mir: "Ja logisch, steht ja auch auf der man page" aber trotzdem wundert es mich, da es ja manuell die ganze Zeit als Hintergrundprozess ohne geöffnetes Terminal-Fenster funktioniert hat. Das hieße, dieses -s Flag, ist nur dazu da, dass FluidSynth vom System gestartet werden kann....? 🤔 Egal, das ist ne Frage für die FluidSynth Entwickler.