mon asoundrc est modifié à chaque redémarrage

Annuler ce que je vous ai demandé de faire. Après cela, redémarrez. Une fois votre RPi sauvegardé, créons un fichier:

sudo nano /etc/asound.conf 

Dans ce fichier, placez-y ceci:

pcm.!default { type asym playback.pcm { type plug slave.pcm "hw:1,0" } capture.pcm { type plug slave.pcm "hw:0,0" } } 

Une fois terminé, enregistrez votre fichier, puis redémarrez.

Commentaires

• Merci Jason mais non. personne ne change Jai déjà pcm.!default et ctl.!default Jessaye de supprimer /home/pi/.asoundrc mais pcm et ctl revenez sans ma configuration dans /etc/asound.conf

Le Jai résolu ce problème en exécutant sudo raspi-config, puis en allant dans Options avancées, puis Audio. Cela a été réglé sur Auto. Lorsque jai changé cette option en « Forcer la prise casque 3,5 mm », cela arrêté décraser mon fichier .asoundrc au redémarrage.

Commentaires

• Jai essayé ceci, quelque chose écrase encore mon .asoundrc fichier à chaque démarrage.

Cest un vieux problème qui refait surface régulièrement, plus récemment après une mise à jour vers le dernier noyau et micrologiciel, pour Raspian Stretch , 4.14.30-v7+.

Il semble que cela puisse avoir quelque chose à voir avec la façon dont les Raspberry Pi utilisent les services systemd lors du démarrage et de larrêt et comment les démons et services ALSA ont été configurés initialement (ou après la mise à niveau du système). Ma meilleure hypothèse est que les scripts de post-installation pour quelque chose ne reconnaissent pas que vous avez déjà un fichier /home/pi/.asoundrc et essaient ensuite de le restaurer à une valeur par défaut. On ne sait pas doù vient cette valeur par défaut. Certainement pas ce qui est écrit dans les commentaires des nombreux fichiers de configuration dALSA ou de services système ou des pages de manuel associées. Mais cela semble provenir dun bogue dans lapplet de volume lxpanels.

Dans mon cas, le Les éléments suivants semblent avoir résolu le problème:

• Supprimez dabord lapplet de volume du lxpanel , puis:

 # Make sure your .asoundrc is correct, then do: alsactl kill save_and_quit sudo shutdown now  

PS. Il semble également important dutiliser shutdown , et non reboot !

Tentatives de débogage

Si ce qui précède ne fonctionne pas, alors lisez ceci.

En tant que côté, il semble y avoir un bogue dans la façon dont systemctl gère les services. Le FS dans le pi est différent (par des parties manquantes) des autres systèmes basés sur Debian, donc où les scripts de service sont localisés et gérés nest pas entièrement selon ses propres pages de manuel.

Pour voir les services pertinents liés à ALSA , faites:

sudo systemctl status alsa-restore alsa-state 

Dans des circonstances normales, vous devriez pouvoir arrêter les services statiques suspects par quelque chose comme:

sudo systemctl mask --system alsa-state.service --now sudo systemctl mask --system alsa-restore.service --now 

Cependant, les emplacements dexécution de [system,user,runtime, global] qui sont:

/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 

ne sont pas respectés comme décrit dans man systemd.preset.
Pour voir tous les services et leur état actuel, utilisez:

systemctl list-unit-files -t service -all 

Vous pouvez également inverser les dépendances avec:

systemctl list-dependencies --reverse alsa-restore.service alsa-restore.service ● └─basic.target ● └─multi-user.target ● └─graphical.target 

Dans tous les cas, lors de la désactivation du service avec mask, il convient de remplacer le fichier par un lien symbolique vers /dev/null, seulement que cela « ne se produit pas au bon endroit (comme ci-dessus). Nous devons donc supprimer le fichier manuellement (le sauvegarder avant), puis créer le lien.

 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  

Maintenant, assurez-vous de répéter ce qui précède également pour alsa-state.service, et les mêmes fichiers dans le répertoire: /lib/systemd/system/ si ce nest déjà fait.

DISCLAIMER

Ce qui précède nest probablement pas la bonne façon de faire ceci, alors considérez ceci comme une solution de contournement très expérimentale jusquà ce que ce problème de buggy ait été résolu. Cela peut très probablement casser complètement votre fonctionnalité ALSA.

Javais résolu une situation similaire en mettant à jour lenvironnement Raspberry pi. les étapes sont:

• Sauvegardez vos données depuis Raspberry pi
• vérifiez votre version actuelle $ uname -a
• mettez à jour les informations du package $ sudo apt-get mise à jour
• mise à jour des packages installés $ sudo apt-get upgrade
• mise à jour vers la dernière distribution $ sudo apt-get dist-upgrade
• mise à jour du micrologiciel raspberry pi $ sudo rpi-update
• reboot $ sudo reboot
• vérifiez votre dernière version $ uname -a

Après cela, sur mon Raspberry pi a été résolu tel comme « .asoundrc modifié a été réécrit après le redémarrage ». La version NOOBS a été mise à jour vers 2.8.1 le 2018-4-24. Juste mon avis, cétait une sorte de bogue ALSA parce que jai essayé et échoué et rassembler quelques informations sur ces phénomènes.

Ok donc jai eu un problème similaire, je me connectais à mon Pi avec un haut-parleur bluetooth, si le haut-parleur nétait pas allumé avant le démarrage, il réinitialiserait le fichier .asoundrc. Tellement irritant. Jai essayé tout ce qui précède, puis je me suis dit que si je définissais simplement les paramètres corrects, je le faisais en lecture seule. Curieusement, cela a fonctionné. Tout ce que jai fait est: sudo chmod 0444 ./.asoundrc et cest tout. Tout va bien maintenant.

Commentaires

• Cela a fonctionné pour moi sur Raspbian Stretch. Il est étrange que la définition des autorisations fonctionne, car jaurais pensé que cétait le système (cest-à-dire root) qui modifiait le fichier.
• Bien que maintenant jobtienne lerreur ci-dessous lors de lappel de pyaudio.  » Expression ‘ alsa_snd_pcm_hw_params_set_period_size_near (pcm, hwParams, & alesPer & dir) ‘ a échoué dans ‘ src / hostapi / alsa / pa_linux_alsa.c ‘, ligne: 924  »

Si vous modifiez le périphérique audio par défaut dans le menu> préférences> Paramètres du périphérique audio> Carte son sélectionnez Carte son> par défaut, votre fichier ~ / .asoundrc sera modifié

Commentaires

• Cela semble être mon problème. Écrasement de .asoundrc au redémarrage avec Stretch. Des idées où je peux ‘ annuler ‘ la vérification de cette case pour que le système nécrase plus?