Audiogerät vom Dienst auf systemd vs. Befehlszeile beschäftigt

Audiogerät vom Dienst auf systemd vs. Befehlszeile beschäftigt

Ein spezielles Problem für mich ist die Verwendung von Snapclient auf einem Raspberry Pi.

Ich habe Snapclient neben einem Sprachassistenten laufen. Wenn ich Snapclient über die Befehlszeile starte

sudo snapclient -h 192.168.x.xxx -s 3 --player=alsa &

dann kann mein Sprachassistent die Ausgabe auf denselben Audioausgang verlagern und ich höre beide Streams.

Wenn ich den systemd-Startup verwende

sudo systemctl start snapclient.service

dann wird der Ton des Sprachassistenten blockiert, weil das Gerät/die Ressource belegt ist.

Mithilfe von htop (es gibt höchstwahrscheinlich eine bessere Möglichkeit, dies zu tun) kann ich den Benutzer und die vollständige Argumentliste sehen, wenn es über systemd gestartet wird, und ich repliziere dies genau, wenn ich es von der Befehlszeile aus ausführe, aber ohne Erfolg.

Kann mir bitte jemand sagen, was ich lernen muss, um dies von systemd aus auf die gleiche Weise ausführen zu können, oder ob es möglicherweise besser wäre, dies über rc.local zu tun? Alle Empfehlungen, wie man dies lernen kann, sind willkommen.

Ich bin sicher, dass es sich wahrscheinlich um ein Berechtigungsproblem handelt, weiß aber nicht, wie ich nach den nächsten Schritten suchen soll.

Antwort1

Ich hatte ein ähnliches Problem bei der Verwendung von Alsa zum Abspielen von Audio von einem Dienst auf Ubuntu/OrangePi: „Audio hw:0 kann nicht geöffnet werden: Gerät oder Ressource beschäftigt.“

Ich konnte das Problem beheben, indem ich der Unit-Konfiguration „Requires=dbus.service“ und „Environment=DISPLAY=:0“ hinzugefügt habe.

Hier ist meine funktionierende Unit-Konfigurationsdatei:

[Unit]
Description=Buttons sound app
Requires=dbus.service

[Service]
ExecStart=/home/orangepi/runSoundServer.sh
User=orangepi
Environment=DISPLAY=:0

[Install]
WantedBy=multi-user.target

verwandte Informationen