min asoundrc er ændret hver genstart

Fortryd det, jeg bad dig om at gøre. Derefter skal du genstarte. Når din RPi er sikkerhedskopieret, skal vi oprette en fil:

sudo nano /etc/asound.conf 

I den fil skal du placere den 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 færdig, skal du gemme din fil og derefter genstarte.

Kommentarer

• Tak Jason men nej. ingen ændringer Jeg har allerede pcm.!default og ctl.!default Jeg prøver at slette /home/pi/.asoundrc men pcm et ctl kom tilbage uden min konfiguration i /etc/asound.conf

måde jeg løste dette problem på var at køre sudo raspi-config og derefter gå til Avancerede indstillinger og derefter Audio. Dette blev indstillet til Auto. Da jeg ændrede denne mulighed til “Force 3.5 mm hovedtelefonstik”, stoppede med at overskrive min .asoundrc-fil ved genstart.

Kommentarer

• Jeg prøvede dette, noget overskriver stadig min .asoundrc fil hver boot.

Dette er et gammelt problem, som gentages regelmæssigt, senest efter en opgradering til den nyeste kerne og firmware, til Raspian Stretch , 4.14.30-v7+.

Det ser ud til, at det kan have noget at gøre med både, hvordan Raspberry Pi “bruger systemd -tjenesterne, når de starter og lukker og hvordan ALSA-dæmoner og tjenester oprindeligt er konfigureret (eller efter systemopgradering). Mit bedste gæt er, at postinstallations-scripts til noget ikke genkender, at du allerede har en /home/pi/.asoundrc -fil og derefter forsøger at gendanne den til nogle standarder. Det er uklart, hvor denne standard kommer fra. Bestemt ikke hvad der er skrevet i kommentarerne fra de mange ALSA- eller systemtjenestekonfigurationsfiler eller relaterede mandesider. Men det ser ud til at komme fra en fejl i lxpanels volumen-applet.

I mit tilfælde er følgende synes at have løst problemet:

• Fjern først volumenapplet fra lxpanel og derefter:

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

PS. Det synes også vigtigt at bruge shutdown og ikke reboot !

Fejlfindingsforsøg

Hvis ovenstående ikke virker, skal du læse dette.

Som en side synes der at være en fejl i, hvordan systemctl håndterer tjenester. FS i pi adskiller sig (ved manglende dele) fra andre Debian-baserede systemer, så hvor serviceskripterne findes og håndteres er ikke fuldt ud i overensstemmelse med dens egne man-sider.

For at se de relevante ALSA-relaterede tjenester , gør:

sudo systemctl status alsa-restore alsa-state 

Under normale omstændigheder skal du kunne lukke de mistænkte statiske tjenester med noget som:

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

Kørselstiderne for [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 at se alle tjenester og deres aktuelle tilstand skal du bruge:

systemctl list-unit-files -t service -all 

Du kan også omvendte afhængigheder med:

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

Under alle omstændigheder, når tjenesten deaktiveres med mask, skal den erstatte filen med et symlink til /dev/null, kun at dette ikke sker på det rigtige sted (ifølge ovenstående). Så i stedet er vi nødt til at fjerne filen manuelt (sikkerhedskopiere den før) og derefter oprette linket.

 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  

Sørg nu for at gentage ovenstående også for alsa-state.service, og de samme filer i biblioteket: /lib/systemd/system/ hvis det ikke allerede er der.

ANSVARSFRASKRIVELSE

Ovenstående er sandsynligvis ikke den rigtige måde at gøre dette, så vær venlig at betragte dette som en meget eksperimentel løsning, indtil den buggy beahviour er løst. Det kan meget sandsynligt bryde din ALSA-funktionalitet helt.

Jeg havde løst en lignende situation ved at opdatere Raspberry pi-miljøet. trinene er,

• Sikkerhedskopier dine data fra Raspberry pi
• tjek din aktuelle version $ uname -a
• opdater pakkeoplysninger $ sudo apt-get opdater
• opdater installerede pakker $ sudo apt-get upgrade
• opdater til nyeste distribution $ sudo apt-get dist-upgrade
• opdater hindbær pi firmware $ sudo rpi-opdatering
• genstart $ sudo genstart
• kontroller dig den nyeste version $ uname -a

Derefter blev min Raspberry pi løst sådan som “modificeret .asoundrc blev omskrevet efter genstart”. NOOBS-versionen blev opdateret til 2.8.1 den 2018-4-24. Bare min mening, at det var en slags ALSA-fejl, fordi jeg prøvede og mislykkedes og indsamlede nogle oplysninger om dette fænomen.

Ok, så jeg havde et lignende problem, jeg oprettede forbindelse til min Pi med en Bluetooth-højttaler, hvis højttaleren ikke var tændt, før jeg startede, ville den genindstille .asoundrc-filen. Så irriterende. Jeg prøvede alt ovenstående, så tænkte jeg, hvad hvis jeg bare indstillede de korrekte indstillinger, så gør det readonly. Mærkeligt nok fungerede dette. Alt, hvad jeg gjorde, var: sudo chmod 0444 ./.asoundrc og at “s it. Alt er godt nu.

Kommentarer

• Dette fungerede for mig på Raspbian Stretch. Underligt at indstilling af tilladelser fungerer, som jeg ville have troet, at det var systemet (dvs. root), der skiftede filen.
• Selvom jeg nu får fejlen nedenfor, når jeg ringer til pyaudio. Ting ser stadig ud skal dog arbejde. ” Udtryk ‘ alsa_snd_pcm_hw_params_set_period_size_near (pcm, hwParams, & als & dir) ‘ mislykkedes i ‘ src / hostapi / alsa / pa_linux_alsa.c ‘, linje: 924 ”