Ich habe einen Himbeer-Pi 3 mit USB-DAC zum Anschließen meines Mikrofons und ich habe auch einen USB-Speacker.
Ich habe auf meinem pi, mopidy und anderen kleinen Projekt installiert.
Ich habe meine ~/.asoundsrc
für
pcm.!default { type asym playback.pcm { type plug slave.pcm "hw:1,0" } capture.pcm { type plug slave.pcm "hw:0,0" } }
Alles funktioniert und beim Neustart wird am Ende meiner .asoundrc
-Datei
pcm.!default { type asym playback.pcm { type plug slave.pcm "hw:1,0" } capture.pcm { type plug slave.pcm "hw:0,0" } } pcm.!default { type hw card 2 } ctl.!default { type hw card 2 }
Mit dieser Änderung funktioniert mein kleines Projekt nicht, ich muss
pcm.!default { type hw card 2 } ctl.!default { type hw card 2 }
löschen. Wissen Sie warum, diese Konfiguration wird jedes Mal hinzugefügt Neustart?
Vielleicht können Sie mir dabei helfen 🙂
cat /proc/asound/modules 0 snd_usb_audio 1 snd_usb_audio 2 snd_bcm2835
Danke
Kommentare
Antwort
Machen Sie rückgängig, was ich Sie gebeten habe. Starten Sie danach neu. Sobald Ihr RPi gesichert ist, erstellen wir eine Datei:
sudo nano /etc/asound.conf
Fügen Sie in diese Datei Folgendes ein:
pcm.!default { type asym playback.pcm { type plug slave.pcm "hw:1,0" } capture.pcm { type plug slave.pcm "hw:0,0" } }
Speichern Sie anschließend Ihre Datei und starten Sie sie neu.
Kommentare
- Danke Jason, aber nein. niemand ändert Ich habe bereits
pcm.!default
undctl.!default
Ich versuche/home/pi/.asoundrc
zu löschen, aber pcm et ctl Kommen Sie ohne meine Konfiguration in/etc/asound.conf
Antwort
zurück Ich habe dieses Problem gelöst, indem ich sudo raspi-config
ausgeführt habe und dann zu Erweiterte Optionen und dann zu Audio gegangen bin. Dies wurde auf Auto eingestellt. Als ich diese Option in „3,5-mm-Kopfhörerbuchse erzwingen“ geändert habe, wurde sie aktiviert Ich habe beim Neustart aufgehört, meine .asoundrc-Datei zu überschreiben.
Kommentare
- Ich habe dies versucht, etwas überschreibt immer noch meine
.asoundrc
Datei bei jedem Start.
Antwort
Dies ist ein altes Problem, das tauchen regelmäßig wieder auf, zuletzt nach einem Upgrade auf den neuesten Kernel und die neueste Firmware für Raspian Stretch , 4.14.30-v7+
.
Es scheint, dass dies etwas damit zu tun hat, wie Raspberry Pi die Dienste systemd beim Booten und Herunterfahren verwenden und wie die ALSA-Dämonen und -Dienste ursprünglich (oder nach dem System-Upgrade) eingerichtet wurden. Ich vermute, dass die Skripte nach der Installation für etwas nicht erkennen, dass Sie bereits eine /home/pi/.asoundrc
-Datei haben, und dann versuchen, diese auf einen Standardwert zurückzusetzen. Es ist unklar, woher dieser Standard kommt. Sicherlich nicht das, was in den Kommentaren der vielen ALSA- oder Systemdienst-Konfigurationsdateien oder verwandten Manpages geschrieben steht. Aber es scheint von einem Fehler im Volume-Applet von lxpanels zu stammen.
In meinem Fall ist das Folgendes scheint das Problem behoben zu haben:
- Entfernen Sie zuerst das Volume-Applet aus dem lxpanel und dann:
# Make sure your .asoundrc is correct, then do: alsactl kill save_and_quit sudo shutdown now
PS. Es scheint auch wichtig zu sein, shutdown zu verwenden und nicht reboot !
Debugging-Versuche
Wenn das oben genannte nicht funktioniert, lesen Sie dies.
Als Seite scheint es eine zu geben Ein Fehler im Umgang von systemctl mit Diensten. Der FS im pi unterscheidet sich (durch fehlende Teile) von anderen Debian-basierten Systemen, sodass der Ort, an dem sich die Service-Skripte befinden und verarbeitet werden, nicht vollständig den eigenen Manpages entspricht.
Anzeigen der relevanten ALSA-bezogenen Services , tun Sie Folgendes:
sudo systemctl status alsa-restore alsa-state
Unter normalen Umständen sollten Sie in der Lage sein, die vermuteten statischen Dienste wie folgt herunterzufahren:
sudo systemctl mask --system alsa-state.service --now sudo systemctl mask --system alsa-restore.service --now
Die Laufzeitpositionen von [system,user,runtime, global]
sind jedoch:
/etc/systemd/system-preset/*.preset /run/systemd/system-preset/*.preset /lib/systemd/system-preset/*.preset /etc/systemd/user-preset/*.preset /run/systemd/user-preset/*.preset /usr/lib/systemd/user-preset/*.preset
werden nicht berücksichtigt, wie in man systemd.preset
beschrieben.
Um alle Dienste und ihren aktuellen Status anzuzeigen, verwenden Sie:
systemctl list-unit-files -t service -all
Sie können die Abhängigkeiten auch umkehren mit:
systemctl list-dependencies --reverse alsa-restore.service alsa-restore.service ● └─basic.target ● └─multi-user.target ● └─graphical.target
Wenn Sie den Dienst mit mask
deaktivieren, sollte die Datei in jedem Fall durch einen Symlink zu /dev/null
, nur dass dies nicht „am richtigen Ort“ geschieht (siehe oben). Stattdessen müssen wir die Datei manuell entfernen (vorher sichern) und dann den Link erstellen.
cp /etc/systemd/system/alsa-restore.service ~/alsa-restore_service.bak cd /etc/systemd/system/ sudo rm alsa-restore.service sudo ln -s /dev/null alsa-restore.service # It should look something like: ls -al /lib/systemd/system |grep alsa lrwxrwxrwx 1 root root 9 Apr 25 13:23 alsa-restore.service -> /dev/null lrwxrwxrwx 1 root root 9 Apr 25 13:26 alsa-state.service -> /dev/null lrwxrwxrwx 1 root root 9 Jan 23 2017 alsa-utils.service -> /dev/null
Wiederholen Sie dies nun auch für alsa-state.service
und die gleichen Dateien im Verzeichnis: /lib/systemd/system/
, falls nicht bereits vorhanden.
HAFTUNGSAUSSCHLUSS
Dies ist höchstwahrscheinlich nicht der richtige Weg Betrachten Sie dies daher als eine sehr experimentelle Lösung, bis das fehlerhafte Verhalten behoben ist. Es kann sehr wahrscheinlich dazu führen, dass Ihre ALSA-Funktionalität insgesamt beeinträchtigt wird.
Antwort
Ich hatte eine ähnliche Situation durch Aktualisieren der Raspberry Pi-Umgebung behoben. Die Schritte sind:
- Sichern Sie Ihre Daten von Raspberry pi
- Überprüfen Sie Ihre aktuelle Version $ uname -a
- Aktualisieren Sie die Paketinformationen $ sudo apt-get Update
- Update installierte Pakete $ sudo apt-get Upgrade
- Update auf die neueste Distribution $ sudo apt-get dist-Upgrade
- Update Himbeer-Pi-Firmware $ sudo rpi-update
- Neustart $ sudo Neustart
- Überprüfen Sie die neueste Version $ uname -a
Danach wurde auf meinem Raspberry pi z als „modifizierte .asoundrc wurde nach dem Neustart neu geschrieben“. Die NOOBS-Version wurde am 24.4.2018 auf 2.8.1 aktualisiert. Nur meine Meinung, dass es eine Art ALSA-Fehler war, weil ich versucht habe und versagt habe und einige Informationen über dieses Phänomen gesammelt habe.
Antwort
Ok, ich hatte ein ähnliches Problem. Ich stellte eine Verbindung zu meinem Pi mit einem Bluetooth-Lautsprecher her. Wenn der Lautsprecher vor dem Booten nicht eingeschaltet war, wurde die .asoundrc-Datei zurückgesetzt. So irritierend. Ich habe alles oben Genannte ausprobiert, dann dachte ich mir, wenn ich nur die richtigen Einstellungen vorgenommen habe, mache ich es schreibgeschützt. Seltsamerweise hat das funktioniert. Alles was ich getan habe war: sudo chmod 0444 ./.asoundrc und das ist alles. Jetzt ist alles in Ordnung.
Kommentare
- Das hat bei mir funktioniert auf Raspbian Stretch. Seltsam, dass das Festlegen von Berechtigungen funktioniert, da ich gedacht hätte, dass das System (dh root) die Datei ändert.
- Obwohl jetzt beim Aufrufen von pyaudio der folgende Fehler angezeigt wird. Die Dinge scheinen immer noch “ Ausdruck ‚ alsa_snd_pcm_hw_params_set_period_size_near (pcm, hwParams, & & dir) ‚ ist in ‚ src / hostapi / alsa / pa_linux_alsa.c ‚, Zeile: 924 “
Antwort
Wenn Sie das Standard-Audiogerät über Menü> Einstellungen> Audio-Geräteeinstellungen> Soundkarte ändern, wählen Sie Soundkarte> Standard festlegen, wird Ihre ~ / .asoundrc-Datei geändert.
Kommentare
- Dies scheint mein Problem zu sein. Überschreiben von .asoundrc beim Neustart mit Stretch. Irgendwelche Ideen, bei denen ich ‚ ‚ das Aktivieren dieses Kontrollkästchens rückgängig machen kann, damit das System nicht mehr überschreibt?
pcm.!default
undctl.!default
neu starte ‚ hat keine Karte 2, sondern Karte 0.