Ich habe ein ähnliches Problem mit Pulseaudio 6.0. Pulseaudio neigt dazu, entweder gar nicht zu spielen oder nach einigen Minuten Wiedergabe zu blockieren. Auch mit Arch Linux. Habe sowohl den Benutzermodus (läuft als root) als auch den Systemmodus ausprobiert, da ich den Pi kopflos eingerichtet habe.

Das Folgende ist der Fehler, den Pulseaudio immer dann druckt, wenn er hängt (normalerweise nach ein oder zwei Minuten Wiedergabe).

E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA hat uns aufgeweckt, um neue Daten auf das Gerät zu schreiben, aber es gab eigentlich nichts zu schreiben!
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Höchstwahrscheinlich handelt es sich um einen Fehler im ALSA-Treiber '(null)'. Bitte melden Sie dieses Problem den ALSA-Entwicklern.
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Wir wurden mit gesetztem POLLOUT geweckt - ein nachfolgender snd_pcm_avail () gab jedoch 0 oder einen anderen Wert <min_avail zurück.

Ich habe auch schreckliche Probleme mit dem bcm2835 und Puls 6.
Wenn ich pulseaudio starte und paplay lokal (auf dem pi) starte, beginnt es sofort mit dem verstümmelten Audio zu spielen. Teile des PCM klingen so, als würden sie nicht in der richtigen Reihenfolge abgespielt. Je länger das Audio abgespielt wird, desto schlechter wird es, bis das Audio fast reines Rauschen ist.
Das Töten (STRG + C) und das anschließende Ausführen von Paplay führt zu einem wiederholbaren Muster des Verstümmelns des Audios oder der reinen Stille, bis beim achten Lauf das Audio perfekt wiedergegeben wird. Spielen Sie es erneut und der Zyklus startet neu.
Das Muster ist verstümmelt, still, verstümmelt, verstümmelt, still, verstümmelt, still, perfekt.
Wenn ich ein USB-Headset verwende, funktioniert Paplay jedes Mal.
Ich hatte es dort, wo ich Audio über das USB-Headset perfekt abgespielt habe, und dann habe ich den USB-Dongle herausgezogen und die Audiowiedergabe korrekt über den analogen Anschluss des Pi abgespielt. Stoppen Sie und starten Sie Audio neu und es wird verstümmelt.

Mein Setup: pulseaudio + mpd + ncmpcpp.

Mein Test-Setup besteht darin, einen Song zu starten und wiederholt abzuspielen / anzuhalten. Nach maximal 3-maliger Wiedergabe / Pause bleibt pulseaudio hängen und muss neu gestartet werden.
Dies geschieht nur auf meinem Raspberry B + mit dem bcm2835-Chip, sowohl mit Debian- als auch mit Arch-basierten Distributionen. Ich habe keine Probleme mit genau dem gleichen Setup auf meinem Desktop-PC mit einem Intel-Soundchip. Das Problem gab es mit Kernel 3.6 nicht (aber ich möchte keine alte Distribution verwenden).

Keine der im Web zu findenden Problemumgehungen (tsched = 0, Deaktivieren von Modul-Suspend-on-Idle, ...) hat funktioniert. Ich werde dieses Problem endlich aufgeben, weil ich seit mehr als einem Jahr keine Lösung mehr gefunden habe. Entweder kaufe ich mir eine Raspberry 2 oder ich verwende mpd mit dem ALSA-Backend, weil das großartig funktioniert.

@maxnet wurde dieses Problem behoben? Wenn ja, schließen Sie dieses Problem.

Das glaube ich nicht. Es funktioniert auch nicht mit Raspberry 3 (was kein Wunder ist, da es denselben Chip / Treiber verwendet: snd_bcm2835).

Ich habe dieses Problem auf meinem Raspberry 3 mit Ubuntu 16.04. Um dieses Problem zu umgehen, werde ich meinem Programm eine Timeout-Verzögerung von 5 Sekunden hinzufügen, was jedoch die Natürlichkeit der Ausgabe beeinträchtigt (es handelt sich um einen Sprachsynthesizer).

Das gleiche Problem mit meinem pi3 und Ubuntu Mate 16.04 und mpd klingt fantastisch, es sei denn, ich ändere die Lautstärke (was zu Stottern oder Klangverlust führt) und verliert unter anderem zufällig den Ton. Wirklich frustrierend.

Gleiches Problem bei Rpi B (nicht 2 oder 3) mit dem neuesten Kernel (684be4bc8cc343f60fdc3240c6d55d41d0a5b56c)

Kann dieses Problem mit einem RPI3 bestätigen, auf dem Linux raspberrypi 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux auf Raspbian ausgeführt wird. Pulseaudio hört normalerweise auf, zwischen Titeln zu spielen, die ich von mpd (von einem anderen Host über das Netzwerk) an ihn weitergebe. Beim Versuch, 24-Bit-Flac-Audio über mpd abzuspielen, wird nur 2 Sekunden abgespielt und friert ein.

Bestätigen des Problems auf rpi3 mit 4.9.30-v7+ . Das Füllen der MPD-Wiedergabeliste und das Starten der Wiedergabe funktionieren normalerweise bis zum Abschluss der Wiedergabeliste. Wenn Sie jedoch die Titel manuell ändern, stoppen und neu starten, funktioniert die Audioausgabe nicht mehr, bis ich die MPD neu starte.

audio_output {
        type            "alsa"
        name            "ALSA Output"
#       device          "hw:0,0"        # optional
        mixer_type      "software"      # optional
#       mixer_device    "default"       # optional
#       mixer_control   "PCM"           # optional
#       mixer_index     "0"             # optional
#       auto_resample   "no"
#       auto_channels   "no"
#       auto_format     "no"
}

Das gleiche problematische Verhalten wie von @flittermice beschrieben : enttäuscht:
Das System ist RPi2, auf dem eine Neuinstallation von Raspbian Stretch (9.1) mit pulseaudio v10.0-1 + deb9u1, Kernel 4.9.59+ ausgeführt wird
Ich habe verwandte Artikel / Tutorials / Threads gelesen, aber die MPD-Wiedergabe hängt wie oben beschrieben, bis ich pulseaudio töte und neu starte.

Hat jemand schon eine Lösung dafür gefunden? : gekreuzte_finger :: lächeln:

Fand etwas Interessantes (vielleicht):
Wenn pulseaudio hängt (wie oben beschrieben), wird durch zweimaliges (!) Ausgeben eines "paplay" -Befehls die Audiowiedergabe fortgesetzt:
$ paplay /usr/share/sounds/alsa/Front_Center.wav

• Beim ersten Mal läuft der Paplay-Befehl ab (oder kann durch Strg + C unterbrochen werden).
• Das zweite Mal, wenn der Befehl paplay funktioniert, wird der Ton von MPD wieder aufgenommen.

Funktioniert für eine zufällige Zeitspanne, dann geht es zurück zu @flittermices Verhalten: schluchzen:

Ich habe mich weiter mit diesem Problem befasst und festgestellt, dass Pulseaudios Verwendung einer esoterischen ALSA-Funktion namens "Zurückspulen" dieses Problem verursacht.
Leider gibt es keine Konfigurationsoption, um PA daran zu hindern, diese Funktion zu verwenden.
Dieser Zweig deaktiviert ihn dauerhaft im Quellcode: https://github.com/strfry/pulseaudio/tree/no_rewind
Wenn Sie es auf Ihrem System erstellen und installieren können, überprüfen Sie bitte, ob dies Ihr Problem behebt.

Ich habe mich weiter mit diesem Thema befasst und festgestellt, dass Pulseaudio eine esoterische ALSA-Funktion verwendet
Das sogenannte "Zurückspulen" verursacht dieses Problem.
Leider gibt es keine Konfigurationsoption, um PA daran zu hindern, diese Funktion zu verwenden.

Aber kann Pulse richtig funktionieren, wenn Sie diese Funktion entfernen?

Beachten Sie, dass ein Teil der Funktionalität, die es als Soundserver bietet, darin besteht, Sound zu mischen, der aus mehreren Anwendungen zusammen stammen kann.
Und ich kann mir vorstellen, dass Sie eine Möglichkeit benötigen, einen Teil des vorhandenen Puffers zu verwerfen, wenn Sie in der Lage sein möchten, dass neue Anwendungen dem Mix sofort Sounds hinzufügen.
Andernfalls können Sie nur am Ende des Puffers neuen Sound hinzufügen und es kommt zu Verzögerungen, die von der Anwendung möglicherweise nicht erwartet werden. Und was für einige Zwecke ein Problem sein kann (z. B. Video mit Ton)

@maxnet Eine ordnungsgemäße Korrektur (meine nicht) würde die Latenz auf einen relativ niedrigen Wert bringen, wodurch das Zurückspulen auf Kosten einer etwas höheren CPU-Last / eines etwas höheren Stromverbrauchs entfällt.
Es funktioniert gut für meine Anwendung mit geringer Latenz, für das Abspielen von Musik mit MPD kann es etwas ärgerlich sein, keinen Rücklauf zu haben (ohne PA zu patchen, um nur Puffer mit geringer Latenz zu erstellen).

Immer eine geringe Latenz zu haben, würde bedeuten, winzige Puffer zu verwenden.
Was für mich auch nicht ideal klingt.

Würde argumentieren, dass eine richtige Lösung im Kernel-Modul wäre ...

@strfry : Beziehung zum Zurückspulen von ALSA klingt vernünftig. Wenn pulseaudio "unglücklich" wird, endet es normalerweise in dieser Zeile:

D: [alsa-sink-bcm2835 ALSA] source.c: Rücklauf verarbeiten ...

Ich stimme jedoch @maxnet einigermaßen zu , und es gibt wahrscheinlich einen Grund, warum ALSA dies überhaupt tut ...: wink:

Ist dies nur auf dem Raspberry Pi nicht funktionsfähig oder ein allgemeines Problem von pulseaudio + ALSA?
Sollen wir dies pulseaudio / ALSA-Entwicklern statt hier melden, da es seit über 3 Jahren immer noch ein Problem ist?

@ pjotrek-b Es ist nur mit der in Raspberry PI integrierten Soundkarte nicht funktionsfähig. Wir verwenden pulseaudio als Netzwerk-Soundserver erfolgreich mit USB-Soundkarte für einige Monate ohne Probleme.

Ich kann die Aussage von @jekhor bestätigen.
Die gleiche Konfiguration funktioniert perfekt mit meiner USB-Soundkarte (snd_usb_audio) auf dem Raspberry Pi.

In der Protokolldatei heißt es: "E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Dies ist höchstwahrscheinlich ein Fehler im ALSA-Treiber '(null)'. Bitte melden Sie dieses Problem den ALSA-Entwicklern." Weiß jemand, wie man das macht?

@jekhor : Danke, dass

Was jetzt rätselhaft ist, ist, dass ich immer dachte, dass es so ist:
application > pulseaudio > ALSA > driver > hardware

Wenn ja, wie können dieselben Anwendungen , bei denen dieses Problem auftritt, einwandfrei funktionieren, wenn ALSA direkt verwendet wird?
application > ALSA > driver > hardware

Wenn dieses Problem speziell für die integrierte RPi-Soundkarte / den integrierten Soundchip von Chipi auftritt, warum treten diese Probleme dann nicht auch bei der Verwendung nur alsa auf? :verwirrt:

@strfry : Ich habe in der Dokumentation von pulseaudio einen ziemlich detaillierten Artikel über "Zurückspulen" gefunden .

Ich habe Teile davon gelesen und es scheint mir jetzt nicht mehr so ​​"esoterisch" zu sein. Seit Sie sich den Code angesehen haben: Irgendwelche Ideen, was dazu führen könnte, dass pulseaudio "stecken bleibt"?
Wie ich oben erwähnt habe, scheint das zweimalige Ausführen von "paplay" einen "Anstoß" zu geben, um wieder an die Arbeit zu gehen ...: smile:

@ pjotrek-b Sicherlich macht es angesichts der Designziele von Pulseaudio Sinn. Es ist "esoterisch" in dem Sinne, dass 99% der normalen ALSA-Anwendungen niemals einen Rücklauf verwenden und somit einen weniger getesteten Pfad im ALSA-Treiber auslösen. Leider fehlt Pulseaudio die Option, die Verwendung dieser möglicherweise fehlerhaften Funktion zu deaktivieren (wie bei anderen, z. B. zeitgesteuerter Planung).
Ich habe die genauen Details nicht getestet, aber im Grunde bleibt Pulseaudio in einer Endlosschleife stecken, da ALSA nicht korrekt meldet, wann es Zeit ist, Audiodaten erneut auf das Gerät zu schreiben.
Trotz der Möglichkeiten, dies auf Pulseaudios Seite zu umgehen, ist dies ein Fehler im ALSA-Treiber.
Mein Verdacht ist, dass das Ausgeben neuer Streams die Ereignisse erzeugt, auf die Pulseaudio wartet, wenn es stecken bleibt.

@flittermice Ich denke, in diesem Fall ist der verantwortliche ALSA-Entwickler einer der Raspberry Pi-Kernel-Entwickler, der den snd_bcm2835-Treiber geschrieben hat. Daher wäre dieses Repository der richtige Ort, um dies zu melden.

Ein einfaches Codebeispiel, das ein eindeutig falsches Verhalten von ALSA beim Zurückspulen zeigt, wäre für die Kernel-Entwickler wahrscheinlich hilfreich, wenn sie sich diesen Fehler genauer ansehen.

@ pjotrek-b Sicherlich macht es angesichts der Designziele von Pulseaudio Sinn. Es ist "esoterisch" in dem Sinne, dass 99% der normalen ALSA-Anwendungen niemals einen Rücklauf verwenden und somit einen weniger getesteten Pfad im ALSA-Treiber auslösen. Leider fehlt Pulseaudio die Option, die Verwendung dieser möglicherweise fehlerhaften Funktion zu deaktivieren (wie bei anderen, z. B. zeitgesteuerter Planung).
Ich habe die genauen Details nicht getestet, aber im Grunde bleibt Pulseaudio in einer Endlosschleife stecken, da ALSA nicht korrekt meldet, wann es Zeit ist, Audiodaten erneut auf das Gerät zu schreiben.
Trotz der Möglichkeiten, dies auf Pulseaudios Seite zu umgehen, ist dies ein Fehler im ALSA-Treiber.
Mein Verdacht ist, dass das Ausgeben neuer Streams die Ereignisse erzeugt, auf die Pulseaudio wartet, wenn es stecken bleibt.

@flittermice Ich denke, in diesem Fall ist der verantwortliche ALSA-Entwickler einer der Raspberry Pi-Kernel-Entwickler, der den snd_bcm2835-Treiber geschrieben hat. Daher wäre dieses Repository der richtige Ort, um dies zu melden.

Ein einfaches Codebeispiel, das ein eindeutig falsches Verhalten von ALSA beim Zurückspulen zeigt, wäre für die Kernel-Entwickler wahrscheinlich hilfreich, wenn sie sich diesen Fehler genauer ansehen.

Wenn ja, wie können dieselben Anwendungen, bei denen dieses Problem auftritt, einwandfrei funktionieren, wenn ALSA direkt verwendet wird?

Anwendungen, die ALSA direkt verwenden, müssen normalerweise nicht zurückspulen.
Sie wissen genau, welchen Sound sie in den kommenden Sekunden abspielen möchten, und senden ihn an das Audiogerät.

Es wird in Situationen verwendet, in denen sich Pläne ändern.
Wenn Pulse das Audio bereits für die nächsten 2 Sekunden an das Gerät gesendet hat und plötzlich ein anderer Pulse-Client eine Verbindung herstellt und auch Sound abspielen möchte - ohne warten zu müssen, bis diese 2 Sekunden abgelaufen sind -, muss er den Sound mitteilen Gerät, um den vorherigen Puffer zu verwerfen und durch neue Daten zu ersetzen, in die der zusätzliche Sound eingemischt ist.

Sicher, wenn Sie winzige Puffer verwenden, die Millisekunden anstelle von Sekunden Audio enthalten, können Sie auf einen Rücklauf verzichten.
Ich denke jedoch nicht, dass dies bevorzugt wird.
Unter Linux gibt es keine Garantie dafür, wie viel CPU-Zeit eine Anwendung benötigt oder ob sie gleichmäßig aufgeteilt wird. Es handelt sich nicht um ein Echtzeit-Betriebssystem.
Wenn eine andere Anwendung viel verwendet und Pulse nicht rechtzeitig ausreicht, um diesen winzigen Puffer jederzeit gefüllt zu halten, wird er unterlaufen und Ihr Sound wird stottern.

Wie ich oben erwähnt habe, scheint das zweimalige Ausführen von "paplay" einen "Anstoß" zu geben, um wieder an die Arbeit zu gehen ...: smile:

Pulse Audio schließt auch die Verbindung zum Audiogerät 5 Sekunden, nachdem der letzte Client, der es verwendet, die Verbindung getrennt hat, wenn während dieser Zeit keine anderen Clients eine Verbindung hergestellt haben.
Und öffnet es erneut, wenn ein Kunde es das nächste Mal verwenden möchte.
Wenn zwischen Ihren Befehlen genügend Zeit liegt, kann dies auch der Grund dafür sein, dass es wieder funktioniert.

@strfry und @maxnet :
Vielen Dank für diese ausführlichen Antworten!

Weiß jemand, ob dies im neuesten Raspbian (mit Kernel 4.14.y) immer noch ein Problem ist?

Dieses Problem wird innerhalb von 30 Tagen geschlossen, sofern keine weiteren Interaktionen veröffentlicht werden. Wenn Sie möchten, dass dieses Problem offen bleibt, fügen Sie bitte einen Kommentar hinzu. Eine geschlossene Ausgabe kann auf Anfrage erneut geöffnet werden.

Ich würde es überprüfen, aber ich habe derzeit keine Zeit, es zu testen ...: enttäuscht:
Nur für den Fall: Darf ich es wieder öffnen, wenn ich es nach 30 Tagen teste und es immer noch ein Problem ist?

Obwohl ich mir ziemlich sicher bin, dass es keine Verbesserungen gegeben hat, kann ich nicht viel für diesen speziellen Fehler beitragen. Ich habe eine externe USB-Soundkarte mit einem PCM2704-Chipsatz gekauft und bin jetzt mit dem Treiber snd_usb_audio zufrieden.
Die Verwendung des HDMI-Ausgangs des Raspi wäre eine gute Option gewesen, aber mein Raspi würde sich sogar weigern, mit dem an den AV-Receiver angeschlossenen HDMI-Kabel zu booten ... aber das ist eine andere Geschichte.

Schließung wegen mangelnder Aktivität. Bitte fordern Sie eine Wiedereröffnung an, wenn Sie der Meinung sind, dass dieses Problem weiterhin relevant ist.

Kann bestätigen, dass dies mit meinem Rasp Pi 3 passiert
Ich verwende ArchARM mit der Kernel-Version 4.14.69

Kann bestätigen, dass dies auf meinem RPI3 immer noch geschieht:

Linux 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux

Beim Versuch, mpd mit pulseaudio zu verwenden, bekomme ich:

Nov 05 09:25:17 noise systemd[1]: Started Music Player Daemon.
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

Gibt es eine Chance, dass wir dieses Problem erneut öffnen können?

Kann bestätigen, dass dies mit meinem Rasp Pi 3 passiert
Ich verwende ArchARM mit der Kernel-Version 4.14.69
Das war wegen falscher Erlaubnis, ich habe es geklappt.

@ l4rzy : du machst uns neugierig. Welche Berechtigungen?

@flittermice :
Ich habe versucht, meinen Raspberry Pi 3 für einen lokalen Netzwerk-Pulse-Audioserver einzurichten. Er funktionierte nahtlos, aber nach einer Weile, in der nichts abgespielt wurde, wurde der Pulse-Audioserver automatisch heruntergefahren. Später installiere ich mpd, um Musik von SoundCloud abzuspielen, die immer eine Verbindung zu Pulse herstellt und sie am Laufen hält. Keine schlechte Problemumgehung, denke ich.

@ l4rzy : richtige Weg :-)

Übrigens: Haben Sie jemals versucht, "module-suspend-on-idle" nicht in default.pa zu laden?

Lademodul Modul-Suspend-On-Idle

@ Flittermice Ich habe es versucht. Hilft nicht.

Pulseaudio arbeitet immer noch nicht mit snd_bcm2835. Können Sie diese Ausgabe bitte erneut öffnen?

Ich kann bestätigen, dass es auch bei mir nicht funktioniert. Ich habe verschiedene Code- und Kompilierungsoptionen getestet und konnte sie nicht zum Laufen bringen. Ich bin auf ArchLinux ARM und der neuesten Software. Ich helfe gerne beim Debuggen, wenn möglich.

Soweit ich das beurteilen kann, liegt das Problem für mich in der Puffergröße, die vom Modul bcm2835_alsa gemeldet wird. Der an den Impuls gemeldete Audiopuffer beträgt 8816 Bit oder gerade genug für ungefähr 1,56 ms Audio von einem Netzwerkstrom. Ich bin nicht genug Hardware-Freak, um die Spezifikationen zu finden, aber hier scheint etwas nicht zu stimmen. Laut ALSA selbst (dh nicht dem Impulsmodul) beträgt die Puffergröße viel logischere 131072 Bits. Wenn ich raten sollte, denkt Puls, dass es den Puffer für die Karte nicht voll halten kann und versucht zurückzuspulen, weil gesagt wird, dass es ein Software-Limit von 8816 Bit gibt ... aber vielleicht bin ich hier weit von der Basis entfernt.

Hatte gerade das gleiche Problem (es ist wirklich ärgerlich), @ JamesH65 ,

Hmmm ... Ich kann dies nicht mit Raspberry Pi 3 B v1.2 und dem neuesten 4.19.34-Kernel reproduzieren (aktualisiert durch rpi-update auf https://github.com/Hexxeh/rpi-firmware/commit/99c274691c07480762dcda91a0ebfe3c4f519307). Ich habe keine Ahnung warum, der Treiber scheint seit 2016 nicht geändert zu sein. Vielleicht einige Änderungen an der VC-Firmware?

Hallo, auf Raspberry Pi 4 B v1.1 hat Kernel 5.3.0-1014 das gleiche Problem mit dem Sound-Fading mit pulseaudio v13.0. Der Ton geht verloren, wenn in pavucontrol ein Stereoausgang ausgewählt wird. Gibt es eine Lösung?

@acegallagher :

Der an den Impuls gemeldete Audiopuffer beträgt 8816 Bit oder gerade genug für ungefähr 1,56 ms Audio von einem Netzwerkstrom.

Ich denke, das liegt daran, dass PulseAudio die Senken standardmäßig als Mono erkennt ( aufgrund dieses Problems ) und die Standardpuffergröße für diese niedriger ist.
Versuchen Sie, die Standard-Profilkonfigurationsdatei von PA so zu aktualisieren, dass stattdessen Stereo-Senken erstellt werden, da PA dadurch Senken mit device.buffering.buffer_size = "17632" , was besser erscheint!

@ olevenets2

Hallo, auf Raspberry Pi 4 B v1.1 hat Kernel 5.3.0-1014 das gleiche Problem mit dem Sound-Fading mit pulseaudio v13.0. Der Ton geht verloren, wenn in pavucontrol ein Stereoausgang ausgewählt wird. Gibt es eine Lösung?

Stellen Sie sicher, dass Sie die Standard-Profilkonfigurationsdatei von PA aktualisieren, damit die Stereoausgabe tatsächlich mit PA auf dem RPI 4 funktioniert, und stellen Sie sicher, dass Sie load-module module-udev-detect und nicht load-module module-alsa-sink in Ihrem /etc/pulse/default.pa .