min asoundrc blir endret hver omstart

Angre det jeg ba deg om å gjøre. Start det på nytt. Når RPi er sikkerhetskopiert, la oss opprette en fil:

sudo nano /etc/asound.conf 

I den filen plasserer du denne i den:

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

Når du er ferdig, lagrer du filen og starter den på nytt.

Kommentarer

• Takk Jason, men nei. ingen endring Jeg har allerede pcm.!default og ctl.!default Jeg prøver å slette /home/pi/.asoundrc men pcm et ctl kom tilbake uten konfigurasjonen min i /etc/asound.conf

måten jeg løste dette problemet på var å kjøre sudo raspi-config og deretter gå til Advanced Options og deretter Audio. Dette ble satt til Auto. Da jeg endret dette alternativet til «Force 3.5mm headphone jack», ble det sluttet å overskrive .asoundrc-filen ved omstart.

Kommentarer

• Jeg prøvde dette, noe overskriver fremdeles .asoundrc fil hver oppstart.

Dette er et gammelt problem som re-overflate regelmessig, sist etter en oppgradering til den siste kjernen og firmware, for Raspian Stretch , 4.14.30-v7+.

Det ser ut til at det kan ha noe å gjøre med både hvordan Raspberry Pi bruker systemd -tjenestene når de starter og slår av og hvordan ALSA-demoner og tjenester er opprettet i utgangspunktet (eller etter systemoppgradering). Min beste gjetning er at postinstallasjonsskriptene for noe ikke gjenkjenner at du allerede har en /home/pi/.asoundrc -fil, og prøver deretter å gjenopprette den til noen standard. Det er uklart hvor denne standard kommer fra. Absolutt ikke det som er skrevet i kommentarene til de mange konfigurasjonsfilene til ALSA eller systemtjenester eller relaterte man-sider. Men det ser ut til at det kommer fra en feil i volumappleten lxpanels.

I mitt tilfelle er følgende ser ut til å ha løst problemet:

• Fjern først volumappleten fra lxpanel og deretter:

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

PS. Det virker også viktig å bruke shutdown , og ikke reboot !

Feilsøkingsforsøk

Hvis ovennevnte ikke fungerer, så les dette.

Som en side ser det ut til å være en feil i hvordan systemctl håndterer tjenester. FS i pi er forskjellig (av manglende deler) fra andre Debian-baserte systemer, så hvor tjenesteskriptene er lokalisert og håndteres, er ikke helt i samsvar med sine egne man-sider.

For å se de relevante ALSA-relaterte tjenestene. , gjør:

sudo systemctl status alsa-restore alsa-state 

Under normale omstendigheter bør du kunne stenge de mistenkte statiske tjenestene med noe som:

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

Imidlertid er kjøretidsstedene til [system,user,runtime, global] som er:

/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 

respekteres ikke som beskrevet i man systemd.preset.
For å se alle tjenestene og deres nåværende tilstand, bruk:

systemctl list-unit-files -t service -all 

Du kan også reversere avhengigheter med:

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

I alle fall, når du deaktiverer tjenesten med mask, bør den erstatte filen med en symlink til /dev/null, bare at dette ikke skjer på rett sted (ifølge ovenfor). Så i stedet må vi fjerne filen manuelt (sikkerhetskopiere den før) og deretter opprette lenken.

 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  

Husk å gjenta ovenstående også for alsa-state.service, og de samme filene i katalogen: /lib/systemd/system/ hvis det ikke allerede er der.

ANSVARSFRASKRIVELSE

Ovennevnte er mest sannsynlig ikke den riktige måten å gjøre dette, så vær så snill å betrakte dette som en veldig eksperimentell løsning til den buggy beahviour er løst. Det kan veldig sannsynlig ødelegge ALSA-funksjonaliteten din helt.

Jeg hadde løst slik som en lignende situasjon ved å oppdatere Raspberry pi-miljøet. trinnene er,

• Sikkerhetskopier dataene dine fra Raspberry pi
• sjekk din nåværende versjon $ uname -a
• oppdater pakkeinformasjonen $ sudo apt-get oppdater
• oppdater installerte pakker $ sudo apt-get upgrade
• oppdater til siste distribusjon $ sudo apt-get dist-upgrade
• oppdater bringebær pi firmware $ sudo rpi-oppdatering
• start på nytt $ sudo omstart
• sjekk du siste versjonen $ uname -a

Etter det ble på Raspberry pi løst slik som «modifisert .asoundrc ble omskrevet etter omstart». NOOBS-versjonen ble oppdatert til 2.8.1 2018-4-24. Bare min mening, at det var en slags ALSA-feil fordi jeg prøvde og mislyktes og samlet litt informasjon om dette fenomenet.

Ok, så jeg hadde et lignende problem, jeg koblet til Pi-en min med en Bluetooth-høyttaler. Hvis høyttaleren ikke var på før jeg startet, ville den satt inn .asoundrc-filen på nytt. Så irriterende. Jeg prøvde alt det ovennevnte, og tenkte hva om jeg bare angir de riktige innstillingene for å gjøre det skrivebeskyttet. Merkelig nok fungerte dette. Alt jeg gjorde var: sudo chmod 0444 ./.asoundrc og at «s it. Alt er bra nå.

Kommentarer

• Dette fungerte for meg på Raspbian Stretch. Merkelig at innstilling av tillatelser fungerer, som jeg hadde trodd det var systemet (dvs. roten) som endret filen.
• Selv om jeg nå får feilen nedenfor når jeg ringer til pyaudio. Ting ser fortsatt ut skal jobbe skjønt. » Uttrykk ‘ alsa_snd_pcm_hw_params_set_period_size_near (pcm, hwParams, & als & dir) ‘ mislyktes i ‘ src / hostapi / alsa / pa_linux_alsa.c ‘, linje: 924 »