Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Comment passer la commande alsactl restore au démarrage de ma session

grandtoubab

a propos de l'ordonnancement du démarrage

who -b donne l'heure du boot

root@debian:/# who -b
         démarrage système 2017-08-18 22:34
root@debian:/#

systemctl status alsa-state.service donne l'heure du démarrage du service qui est en condition obligatoire

root@debian:/# systemctl status alsa-state.service
● alsa-state.service - Manage Sound Card State (restore and store)
   Loaded: loaded (/lib/systemd/system/alsa-state.service; static; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Fri 2017-08-18 22:34:57 CEST; 1h 45min ago
           └─ ConditionPathExists=/etc/alsa/state-daemon.conf was not met
     Docs: man:alsactl(1)
root@debian:/#

systemctl status alsa-restore.service donne l'heure de début et de fin du service restore

root@debian:/# systemctl status alsa-restore.service
● alsa-restore.service - Save/Restore Sound Card State
   Loaded: loaded (/lib/systemd/system/alsa-restore.service; static; vendor preset: enabled)
   Active: active (exited) since Fri 2017-08-18 22:35:58 CEST; 1h 46min ago
     Docs: man:alsactl(1)
  Process: 1592 ExecStart=/usr/sbin/alsactl -E HOME=/var/lib/alsa restore (code=exited, status=0/SUCCESS)
  Process: 559 ExecStartPre=/bin/sleep 60 (code=exited, status=0/SUCCESS)
 Main PID: 1592 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/alsa-restore.service

août 18 22:34:57 debian systemd[1]: Starting Save/Restore Sound Card State...
août 18 22:35:58 debian systemd[1]: Started Save/Restore Sound Card State.

donc dans mon cas
- boot à 22:34
- alsa-state.service à 22:34:57
- alsa-restore.service début à 22:34:57
- alsa-restore.service fin à 22:35:58

Tout cela est clair le service restore démarre à la 57 ieme seconde et fini après 1mn d'attente à 1mn 58s, au total le service restore est exécuté en 1mn1s

ylag

@grandtoubab :

Salut,

Tout cela est clair le service restore démarre à la 57 ieme seconde et fini après 1mn d'attente à 1mn 58s, au total le service restore est exécuté en 1mn1s

Si tu pouvais faire en sorte que le lancement du service débute le plus tard possible dans la séquence de boot (faisable...?), serait-ce suffisant pour que les paramètres soient effectivement restaurés, sans pour autant avoir à allonger la durée du démarrage avec la commande sleep ?

As-tu examiné le retour de :

systemd-analyze plot > fichier.svg

?

Encore merci de prendre le temps de te pencher sur ce cas...

A+

ylag

@jecarpi :

Salut,

Concernant la commande alsactl restore passée dans le fichier ~~.bashrc~~ .profile de ton utilisateur, il existe une façon plus "propre" d'exécuter cette commande sans avoir à utiliser sudo: Il s'agit de donner les droits de superutilisateur sur la commande alsactl à l'utilisateur caron par l'entremise du fichier sudoers.

Par contre, cette manip est généralement considérée comme une brèche dans la sécurité du système, car cela rend possible toute exécution de commandes utilisant alsactl dans l'espace utilisateur sans avoir à passer en "root" via l'utilisation de sudo.

La procédure à suivre pour ce faire serait:

1) Vérifier que ton fichier /etc/sudoers se termine par cette ligne :

#includedir /etc/sudoers.d

Pour ce faire :

sudo cat /etc/sudoers

2) Si cette ligne existe, on crée un fichier nommé alsactl dans le sous-dossier /etc/sudoers.d contenant : caron ALL=/usr/sbin/alsactl
Utilise cette commande pour ce faire :

echo "caron   ALL=/usr/sbin/alsactl" | sudo tee /etc/sudoers.d/alsactl

Une fois cette manip effectuée, l'utilisateur caron n'a plus besoin de sudo pour lancer alsactl.

À toi de voir...

A+

grandtoubab

ylag a écrit@grandtoubab :

Salut,
Tout cela est clair le service restore démarre à la 57 ieme seconde et fini après 1mn d'attente à 1mn 58s, au total le service restore est exécuté en 1mn1s
+

transformer les infos en image n'a pas d'interet pour moi, c'est simplement de la présentation, le fonctionnement est clair je l'ai décrit au-dessus
Pour le reste j'ai déja répondu
Mais dans tout ça je ne vois pas de service audio permettant d'être certain que la carte audio est totalement initialisée avant qu'on déclenche le restore

Le fonctionnement avec la tempo de 60 secondes me convient, les parametres alsa sont bien restaurés
Affaire terminée pour moi.

ylag

@grandtoubab :

grandtoubab a écritAffaire terminée pour moi.

D'accord. Je vais tester le tout un certain temps sur mon système.
Au risque de me répéter : Un grand merci à toi 🙂

A+

ylag

@jecarpi :

Salut,

Tu peux aussi tester la modification de grandtoubab: Il s'agit de modifier ton fichier alsa-restore.service de façon à ce qu'il contienne ceci :

#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#

[Unit]
Description=Save/Restore Sound Card State
ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
After=alsa-state.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=/bin/sleep 60
ExecStart=-/usr/sbin/alsactl -E HOME=/var/lib/alsa restore
ExecStop=-/usr/sbin/alsactl -E HOME=/var/lib/alsa store

Possible de le faire via nano ou leafpad, selon ta préférence.

Important: Faire une sauvegarde du fichier original avant de procéder :

sudo cp /lib/systemd/system/alsa-restore.service /lib/systemd/system/alsa-restore.service.bak

Ensuite ouvrir en superutilisateur le fichier /lib/systemd/system/alsa-restore.service et remplacer son contenu par le le contenu de l'encart ci-haut (utilise copier/coller pour le faire, c'est plus sûr).
Enregistrer et fermer le nouveau fichier.

Si tu tentes cette manip, efface la ligne ajoutée dans ton ~~.bashrc~~ .profile et ne fait pas la manip suggérée au #63. Si tu l'as déjà faite, détruit le fichier créé avec la commande :

sudo rm /etc/sudoers.d/alsactl

Redémarrage et/ou réouverture de session pour vérifier le bon fonctionnement.

Si ça ne fonctionne pas de façon satisfaisante pour toi :

sudo mv /lib/systemd/system/alsa-restore.service.bak /lib/systemd/system/alsa-restore.service

...pour effacer le fichier modifié et restaurer l'original.

A+

Ajout: Si tu utilises le fichier alsa-restore.service modifié, il sera probablement écrasé lors de mises à jour éventuelles du paquet alsa-utils: prévoir d'en faire une copie pour pouvoir restaurer les modifs facilement.

ylag

@jecarpi :

Salut,

Au sujet du bandeau "Headphone" remis à "MM" dans alsamixer, je crois que c'est un comportement normal de la gestion du son lorsqu'il n'y a pas de casque de branché : le son est alors redirigé vers les hauts-parleurs.

Lorsque l'on branche un casque, le système doit mettre les hauts-parleurs en sourdine, "MM", pour n'envoyer le son que vers la sortie casque ?

Est-ce le rôle de la fonction "Auto-Mute" (qui doit être marquée "Enabled" pour que ça fonctionne) dans alsamixer ?

Je crois que si "Auto-Mute" est désactivé, vous aurez alors le son à la fois dans le casque et les hauts-parleurs ...?

Chez-moi je n'ai que des HP branchés, pas de casque disponible pour vérifier ...

A+

grandtoubab

quelques changements pour que ce soit plus robuste

- 1)utilisation d'un fichier spécifique de façon a ce que alsa n'y touche pas lors de l'utilisation d'autres outils

/lib/systemd/system/alsa-restore.service

#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#

[Unit]
Description=Save/Restore Sound Card State
Documentation=man:alsactl(1)
ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
After=alsa-state.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=/bin/sleep 60
ExecStart=-/usr/sbin/alsactl -f /var/lib/alsa/save.asound.state restore
ExecStop=-/usr/sbin/alsactl  -f /var/lib/alsa/save.asound.state store

-2) plus particulier a mon matériel, j'ai deux éléments qui peuvent gérer du son:

lspci -nnk | grep -i audio -A2
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40)
	Subsystem: Hewlett-Packard Company SBx00 Azalia (Intel HDA) [103c:1443]
	Kernel driver in use: snd_hda_intel
--
02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cedar HDMI Audio [Radeon HD 5400/6300/7300 Series] [1002:aa68] (rev ff)
	Kernel modules: snd_hda_intel

je demande au driver d'utiliser les réglages en mode automatique
je garde la carte audio -> 1
je masque le hdmi -> 0

root@debian:/etc/modprobe.d# cat snd_hda_intel.conf 
options snd_hda_intel model=auto
options snd_hda_intel enable=1,0

grandtoubab

ylag a écrit@grandtoubab :
Si tu pouvais faire en sorte que le lancement du service débute le plus tard possible dans la séquence de boot (faisable...?), serait-ce suffisant pour que les paramètres soient effectivement restaurés, sans pour autant avoir à allonger la durée du démarrage avec la commande sleep ?

je m'y suis remis ce matin et voila l'état

cat /lib/systemd/system/alsa-restore.service
#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#

[Unit]
Description=Save/Restore Sound Card State
Documentation=man:alsactl(1)
ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
After=graphical.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=/bin/sleep 27
ExecStart=-/usr/sbin/alsactl -f /var/lib/alsa/save.asound.state restore
ExecStop=-/usr/sbin/alsactl  -f /var/lib/alsa/save.asound.state store

Donc même en conditionnant à un service tardif, il me faut une tempo pour que les niveaux alsa soient bien restaurés.
Je reste persuadé que pendant l'ouverture de session les niveaux sont réinitialisés et il faut donc que le restore intervienne après cette tâche que je ne sais pas déterminer

Ce compromis m'amene à un démarrage en:

 systemd-analyze
Startup finished in 7.033s (kernel) + 1min 3.054s (userspace) = 1min 10.088s

c'est donc comme le fromage, affinage maison jusqu'au bon moment :lol: :lol: :lol:

ylag

@grandtoubab :

Salut,

grandtoubab a écritJe reste persuadé que pendant l'ouverture de session les niveaux sont réinitialisés et il faut donc que le restore intervienne après cette tâche que je ne sais pas déterminer

J'avais essayé aussi avec After=graphical.target sans que ça donne de résultat concluant.

À part ta modification à alsa-restore.service, la seule "bidouille" qui me semble permettre de lancer /usr/sbin/alsactl restore en ouverture de session est d'ajouter la commande au fichier ~~.bashrc~~ .profile de l'utilisateur concerné, tout en lui donnant les droits d'exécution sur alsactl par l'entremise d'un fichier de conf dans /etc/sudoers.d, mais ça ne me semble pas l'idéal question sécurité.

Pour ma part, les réglages de son semblent restaurés normalement, mon niveau sonore des hauts-parleurs est toujours le même à chaque nouvelle session avec le alsa-restore.service de base, et je ne possède pas de casque d'écoute pour tester, faudrait voir où jecarpi en est de son côté.

A+

grandtoubab

une autre bidouille possible

dans les données de conf de l'utilisateur ~/.config/autostart créer un lanceur

:~/.config/autostart$ cat alsa-restore.desktop
[Desktop Entry]
Name=Alsa Restore
Name[fr]=Restauration Alsa
Comment=Restore alsa level
Comment[fr]=Restaurer les niveaux Alsa
Exec=pkexec /usr/sbin/alsactl restore
Terminal=false
Type=Application

je lui ai mis les droits 755

il est bien lancé à l'ouverture de session avec affichage de la fenêtre de saisi du mot de passe, c'est pas si mal

ylag

Salut,

J'avais proposé une manip du genre à jecarpi : https://forum.ubuntu-fr.org/viewtopic.php?pid=21777519#p21777519 en lui suggérant de ne pas tenter si le dossier ~/.config/autostart/ n'existait pas déjà sur son système, ce qui semblait être son cas, donc pas tenté la manip. Est-ce que ça pourrait fonctionner sans casse sous Lubuntu en créant ce dossier à la main ?

Ça semblerait être la solution idéale, à mon avis. 🙂

A+++

grandtoubab

ylag a écritSalut,

J'avais proposé une manip du genre à jecarpi : https://forum.ubuntu-fr.org/viewtopic.php?pid=21777519#p21777519 en lui suggérant de ne pas tenter si le dossier ~/.config/autostart/ n'existait pas déjà sur son système, ce qui semblait être son cas, donc pas tenté la manip. Est-ce que ça pourrait fonctionner sans casse sous Lubuntu en créant ce dossier à la main ?

Ça semblerait être la solution idéale, à mon avis. 🙂

A+++

je ne sais pas
mais creer un dossier avec les droits de l'utilisateur c'est pas méchant de toute façon

ylag

@grandtoubab :

Salut,

grandtoubab a écritmais creer un dossier avec les droits de l'utilisateur c'est pas méchant de toute façon

Ça serait donc une piste vraiment intéressante.

Par contre, serait-il acceptable de ne pas utiliser pkexec pour lancer la commande, et de plutôt donner les droits d'exécution à l'utilisateur sur la commande alsactl via la création d'un fichier de conf dans /etc/sudoers.d, comme suggéré au #70 ?
En se servant de pkexec, l'utilisateur aura toujours une fenêtre "pop-up" lui demandant d'entrer à nouveau son mot de passe immédiatement après l'avoir fait pour ouvrir sa session: ça pourrait devenir un irritant ?

A+

Ajout: J'ai parcouru ta discussion sur debian-fr....
Petite expérience: Avec alsamixer ouvert dans un terminal, les paramètres semblent ne pas être restaurés de la même façon selon que l'on lance dans une autre fenêtre de terminal sudo alsactl restore (en root) ou simplement alsactl restore, en utilisateur normal (testé sur Ubuntu 16.04) ?

grandtoubab

ylag a écrit@grandtoubab :
Par contre, serait-il acceptable de ne pas utiliser pkexec pour lancer la commande, et de plutôt donner les droits d'exécution à l'utilisateur sur la commande alsactl via la création d'un fichier de conf dans /etc/sudoers.d, comme suggéré au #70 ?
En se servant de pkexec, l'utilisateur aura toujours une fenêtre "pop-up" lui demandant d'entrer à nouveau son mot de passe immédiatement après l'avoir fait pour ouvrir sa session: ça pourrait devenir un irritant ?

A+

on a maintenant 3 possibilités
- 1) modifier le service en introduisant une tempo, transparent pour tous les utilisateurs mais ralenti légèrement le boot
- 2) modifier le bash de l'utilisateur, transparent mais pour 1 seul utilisateur et oblige de modifier les règles de sécurité
- 3) ajouter un lanceur en démarrage de la session de l'utilisateur mais demande la saisi du mot de passe

Le choix est affaire de gout, j'ai fait le choix 1

Tu ne peux pas lancer alsactl en utilisateur simple (prompt $) sur Debian il faut etre root (prompt #) ou utiliser sudo
De plus quand alsactl restore échoue on provoque une séquence d'init cf le man alsactl
restore loads driver state for the selected soundcard from the configuration file. If restoring fails (eventu‐
ally partly), the init action is called.
ce qui peut etre le cas si la regle udev ne fonctionne pas bien, c'est pourquoi je l'ai purement et simplement supprimée

ylag

@grandtoubab

Salut,

Je crois que ton commentaire #75 résume fort bien la chose, à jecarpi de voir maintenant...

Encore merci ...

Ajout: La piste du fichier .bashrc n'est pas bonne, il faut plutôt utiliser le fichier .profile
.bashrc n'est pas lu à l'ouverture d'une session, mais plutôt au lancemant d'un "shell" non-interactif, par exemple lors de l'ouverture du terminal, tandis que .profile est lu au lancement d'un "shell" interactif, comme lors de l'ouverture d'une session: Mon erreur, je corrige dans les posts où je suggère .bashrc.

Cordialement.

grandtoubab

Salut
D'autres considérations, ce matin

- le service avec tempo a sa limite, c'est le moment ou l'utilisateur va ouvrir sa session. Si la tempo a claqué avant l'ouverture de session je m'aperçois que le niveau d'alsamixer est mauvais. Quand j'ai un rythme rapide d'ouverture de session, la tempo claque après l'ouverture de session et les niveaux sont bien restaurés
- pour un fonctionnement à 100% il vaut donc mieux lier le alsactl restore à l'ouverture de session

je vais voir comment gérer un service qui ne serait pas un service système mais un service lié a l'utilisateur c'est à dire plûtot que alsa-restore soit dans /lib/systemd/system le mettre dans /lib/systemd/system/multi-user.target.wants ou /usr/lib/systemd/user/

grandtoubab

grandtoubab a écritSalut
D'autres considérations, ce matin

- le service avec tempo a sa limite, c'est le moment ou l'utilisateur va ouvrir sa session. Si la tempo a claqué avant l'ouverture de session je m'aperçois que le niveau d'alsamixer est mauvais. Quand j'ai un rythme rapide d'ouverture de session, la tempo claque après l'ouverture de session et les niveaux sont bien restaurés
- pour un fonctionnement à 100% il vaut donc mieux lier le alsactl restore à l'ouverture de session

je vais voir comment gérer un service qui ne serait pas un service système mais un service lié a l'utilisateur c'est à dire plûtot que alsa-restore soit dans /lib/systemd/system le mettre dans /lib/systemd/system/multi-user.target.wants ou /usr/lib/systemd/user/

c'est possible de gerer des service par utilisateur dans.local/share/systemd/user
puis ça se gere avec la commande systemctl --user

~/.local/share/systemd/user$ cat alsa-restore-perso.service

[Unit]
Description=Alsamixer restore level
Documentation=man:alsactl(1)
After=display-manager.service

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 30
ExecStart=-/usr/bin/pkexec /usr/sbin/alsactl -f /var/lib/alsa/save.asound.state restore

[Install]
WantedBy=default.target

systemctl --user start alsa-restore-perso.service

systemctl --user enable alsa-restore-perso.service

systemctl --user status alsa-restore-perso.service

toujours le meme principe en user ordinaire, alsactl demande la mot de passe

Tout va bien quand je teste le service en mode console, mais à l'ouverture de session ça ne fonctionne pas car pkexec se plaint de ne pas savoir quel terminal utilser pour afficher la fenetre de saisi du mot de passe je ne sais pas comment configurer pour utiliser le tty 7 qui est celui de la session graphique. j'atteinds mon niveau d'incompétence 🙂
De toute façon c'était pour la beauté du geste car ça revient à faire différemment le même fonctionnement que le mode lanceur dans autostart

ylag

@grandtoubab :

Salut,

J'essaie de te résumer le plus clairement possible le comportement de la restauration sur mon système (Ubuntu 16.04 Unity) avec les réglages par défaut, sans utiliser de modifications à alsa-restore.service.

Il n'y a que des hauts-parleurs branchés sur le "jack" vert-pâle de ma carte-mère (matos ancien, carte-mère GA-P35-S3G). Pas de casque de branché.

Dans alsamixer, Le canal "Auto-mute" est à "Enabled".
Je modifie le niveau sonore du canal "Master", et passe le canal "Headphone" de "MM" à "OO", puis sort d'alsamixer en tapant simplement Échap, et ne fait pas sudo alsactl store, ni sudo alsactl restore.

Lors d'un démarrage, redémarrage ou fermeture/réouverture de session subséquents, la config du niveau sonore dans alsamixer pour le canal "Master" est restaurée à la même valeur que lors de la fermeture précédente, mais le canal "Headphone" est restauré à "MM" même si je l'avais placé sur "OO" avant la fermeture.

Pour le canal "Headphone", ne serait-ce pas le comportement normal du système, qui serait géré par la fonction "Auto-mute" ?

En espérant que ça puisse t'être d'une certaine utilité...

A+

jecarpi

Bonjour
Des choses curieuses se passent... Voici:
Remise à niveau des bandeaux dans alsamixer
suivi de sudo alsactl store
Redémarrage
L'icône son du bureau est à 100%
Lecture d'une vidéo: pas de son
Puis CTRL ALT T (sans taper de commande) l'icône son passe brusquement à 41%!!
Lecture vidéo: son mais à 41%
Est-il normal que le simple fait de taper ctrl alt t redonne le son?

« Page précédente Page suivante »