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

ylag · Le 18/08/2017, à 18:18

@ jecarpi :

Salut,

NOTE: Il faut plutôt utiliser le fichier .profile

Si tu désires tenter la piste du fichier .bashrc .profile

Ce fichier est dans ton /home, à /home/caron/.profile
Ouvrir dans un éditeur de texte, est-ce leafpad sous Lubuntu ?
Ajouter après la dernière ligne du fichier :

alsactl restore 2>/dev/null

...enregistrer et fermer le fichier, puis fermer et réouvrir ta session pour tester le tout.

Il est possible de passer par nano, si tu préfères. Dans ton cas, ce serait :

nano /home/caron/.profile

...pour ouvrir le fichier dans nano. Positionne le curseur tout en bas du fichier avec les flèches du clavier et ajoute la ligne citée plus haut.
Faire ensuite Ctrl+O (lettre "o") pour écrire la modif suivi de Enter pour enregistrer le fichier et de Ctrl+X pour fermer nano.

Note qu'il faudra toujours passer la commande :

sudo alsactl store

...après chaque modification faite dans alsamixer pour que la commande de restauration puisse fonctionner, à mon avis.

Ce n'est qu'une manip de contournement, pour dépanner en attendant la vraie résolution du problème; @grandtoubab semble sur une bonne piste...

A+

Note: Le fichier se nomme .bashrc, avec un "." au début, et non pas bashrc

Dernière modification par ylag (Le 20/08/2017, à 23:44)

ylag · Le 18/08/2017, à 18:29

@ grandtoubab :

Salut,

grandtoubab a écrit :

Effectivement en temporisant le service de 60 s la restauration de tous les niveaux est ok

Je ne suis pas certain de te suivre: Est-ce à dire que tu as modifié la valeur sleep 30 en sleep 60 dans ton alsa-restore.service pour que toutes tes valeurs soient bien restaurées ?
Est-ce que ça fonctionne lors d'une fermeture - réouverture de session ?

A+

Dernière modification par ylag (Le 18/08/2017, à 18:33)

grandtoubab · Le 18/08/2017, à 18:44

ylag a écrit :

@ grandtoubab :
Salut,
grandtoubab a écrit :
Effectivement en temporisant le service de 60 s la restauration de tous les niveaux est ok
Je ne suis pas certain de te suivre: Est-ce à dire que tu as modifié la valeur sleep 30 en sleep 60 dans ton alsa-restore.service pour que toutes tes valeurs soient bien restaurées ?
Est-ce que ça fonctionne lors d'une fermeture - réouverture de session ?
A+

oui j'ai mis 60

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=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

et comme ça la restauration a bien lieu à la fin de toutes les actions du driver snd, cf les traces de mon message plus haut
https://forum.ubuntu-fr.org/viewtopic.p … #p21781015
mon PC Debian boot rapidement je ne ferme pas la session, j'éteins le PC donc ça ne me pré-occupe pas

Dernière modification par grandtoubab (Le 18/08/2017, à 18:47)

ylag · Le 18/08/2017, à 18:48

@ grandtoubab :

grandtoubab a écrit :

mon PC Debian boot rapidement je ne ferme pas la session

...une vraie F1, ta machine !!!
Je teste avec sleep 60, et reviendrai dire ce qu'il en est sur mon ordi dans les prochains jours...

Merci encore de ta persévérance.

A+

Dernière modification par ylag (Le 18/08/2017, à 18:49)

grandtoubab · Le 18/08/2017, à 18:51

ylag a écrit :

@ grandtoubab :
grandtoubab a écrit :
mon PC Debian boot rapidement je ne ferme pas la session
...une vraie F1, ta machine !!!
Je teste avec sleep 60, et reviendrai dire ce qu'il en est sur mon ordi dans les prochains jours...
A+

Economie d'énergie
mais maintenant j'ai rallongé le temps avec cette tempo en plus

 systemd-analyze
Startup finished in 7.621s (kernel) + 1min 15.992s (userspace) = 1min 23.613s

jecarpi · Le 18/08/2017, à 18:59

Salut
En réponse au #51, j'ai utilisé leafpad pour ajouter la ligne alsactl restore 2>/dev/null.
Il y a bien une modif avec alsamixer. Toujours pas de son sauf après un sudo alsactl restore. Le 2ème bandeau (headphone) est OK mais c'est le premier (master) qui se positionne à 41.
Cette valeur 41 apparaît à chaque redémarrage

ylag · Le 18/08/2017, à 20:16

@ jecarpi

Je ne comprends pas très bien ta dernière intervention, désolé.
Est-ce que le bandeau Master est en "MM", ce qui signifie "muted" pour sourdine activée, ou en "OO", signifiant que le canal serait ouvert avec la valeur 41 ?
Si c'est "OO", 41 devrait être suffisant pour entendre quelque chose...?

Malheureusenment, je ne connais pas du tout le bureau de Lubuntu, mais s'il y a un icône quelconque pour le contrôle du son, utilise-le pour régler le volume, puis ensuite repasse la commande sudo alsactl store sans passer par alsamixer et relance ensuite une nouvelle session et/ou redémarre pour voir si cette config tient le coup.

Sur mon système Ubuntu 16.04 avec bureau Unity, le volume sonore sur mes HP semble toujours restauré à la valeur déterminée par le contrôle du niveau dans l'icône son sur le bureau...

A+

Dernière modification par ylag (Le 18/08/2017, à 20:39)

ylag · Le 18/08/2017, à 20:30

@grandtoubab:

mais maintenant j'ai rallongé le temps avec cette tempo en plus

Y aurait-il moyen de retarder suffisamment le démarrage de ce service avec une ligne du genre de : After=unServiceQuelconque.service dans la partie [Unit] du service alsa-restore.service ?

Ça éviterait d'avoir à recourir à la commande sleep ?

A+

Dernière modification par ylag (Le 18/08/2017, à 20:30)

grandtoubab · Le 18/08/2017, à 21:52

ylag a écrit :

Ça éviterait d'avoir à recourir à la commande sleep ?
A+

l'ordonnancement des services est listé par la commande systemd-analyze blame et on voit bien que maintenant alsa-restore.service est l'argement le dernier.
appuyer sur espace plusieurs fois pour avoir tout le listage puis q pour quitter

systemd-analyze blame
     1min 1.124s alsa-restore.service
          8.107s winbind.service
          8.061s NetworkManager-wait-online.service
          7.335s exim4.service
          6.327s minidlna.service
          5.653s dev-sda1.device
          5.289s networking.service
          4.437s ModemManager.service
          4.018s accounts-daemon.service
          3.857s ufw.service
          3.773s NetworkManager.service
          3.248s iio-sensor-proxy.service
          2.790s lm-sensors.service
          2.767s pppd-dns.service
          2.129s systemd-rfkill.service
          2.034s udisks2.service
          1.856s apparmor.service
          1.771s bluetooth.service
          1.479s keyboard-setup.service
          1.441s rsyslog.service
          1.393s packagekit.service
          1.187s avahi-daemon.service
          1.135s wpa_supplicant.service
          1.030s systemd-modules-load.service
          1.009s systemd-tmpfiles-setup-dev.service
           964ms polkit.service
           951ms apmd.service
           920ms rtkit-daemon.service
           902ms systemd-udevd.service
           898ms speech-dispatcher.service
           865ms colord.service
           802ms systemd-fsck@dev-disk-by\x2duuid-0231cd69\x2d6248\x2d497c\x2da18c\x2d4d5c92666f35.service
           765ms hddtemp.service
           662ms binfmt-support.service
           597ms systemd-logind.service
           596ms rpcbind.service
           565ms dev-mqueue.mount
           506ms sys-kernel-debug.mount
           491ms systemd-remount-fs.service
           468ms dev-hugepages.mount
           453ms tmp.mount
           392ms dev-disk-by\x2duuid-60e41088\x2d15f8\x2d4d62\x2d93ba\x2d4bfcbf36c48f.swap
           365ms upower.service
           308ms systemd-udev-trigger.service
           304ms systemd-journald.service
           286ms systemd-journal-flush.service
           228ms systemd-random-seed.service
           224ms systemd-update-utmp.service
           222ms systemd-timesyncd.service
           215ms systemd-backlight@backlight:acpi_video0.service
           214ms plexmediaserver.service
           210ms systemd-backlight@backlight:acpi_video1.service
           207ms kmod-static-nodes.service
           189ms geoclue.service
           178ms console-setup.service
           169ms home.mount
           159ms systemd-sysctl.service
           149ms systemd-user-sessions.service
           147ms user@1001.service
           133ms systemd-backlight@backlight:radeon_bl0.service
            90ms rc-local.service
            83ms systemd-tmpfiles-setup.service
            49ms proc-sys-fs-binfmt_misc.mount
            33ms sddm.service
            19ms systemd-backlight@backlight:radeon_bl1.service
            11ms systemd-update-utmp-runlevel.service
             5ms sys-fs-fuse-connections.mount

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

NB
je ne comprends pas ce que peut déclencher la ligne alsactl restore 2>/dev/null car sans sudo la commande part en erreur si c'est l'utilisateur ordinaire

debian:~$ alsactl restore
bash: alsactl : commande introuvable

Dernière modification par grandtoubab (Le 18/08/2017, à 22:04)

ylag · Le 18/08/2017, à 23:20

@grandtoubab :

Salut,

Le but d'ajouter 2>/dev/null à la commande alsactl restore est de pouvoir la lancer en "user" sans polluer le terminal avec des messages d'erreur. Chez-moi, ça semble marcher et la commande restore fonctionne ainsi à partir du fichier .bashrc .profile
Si je ne mets pas la redirection vers /dev/null, on a ces messages dans le terminal lorsqu'on le lance pour la première fois dans une nouvelle session, tel que ceci :

yvan@yvan-maison:~$ alsactl restore
alsactl: state_lock:125: file /var/lib/alsa/asound.state lock error: File exists
alsactl: load_state:1683: Cannot open /var/lib/alsa/asound.state for reading: File exists
Found hardware: "HDA-Intel" "Realtek ALC662 rev1" "HDA:10ec0662,1458a002,00100101" "0x1458" "0xa002"
Hardware is initialized using a generic method
yvan@yvan-maison:~$

Concernant le retour de systemd-analyze blame, je crois que ce n'est pas archivé selon l'ordre de lancement des divers services, mais plutôt selon le temps requis pour les lancer, en ordre décroissant.

Pour avoir une image vraie du processus de démarrage, il faut plutôt :

systemd-analyze plot > fichier.svg

...qui crée un fichier-image au format SVG (scalable vector graphics) dans le dossier courant. Mon expérience est que ces fichiers se manipulent fort bien dans un navigateur web, Firefox ou autre...

Si le service alsa-restore.service est listé tout au bas du retour de systemd-analyze blame, c'est qu'il se lance à la vitesse de l'éclair ?

A+

Ajout:
Pour info, le retour de systemd-analyze blame sur ma machine Ubuntu 16.04 :

yvan@yvan-maison:~$ systemd-analyze blame --no-pager
          7.051s NetworkManager-wait-online.service
           911ms dev-sda1.device
           894ms NetworkManager.service
           855ms speech-dispatcher.service
           843ms lm-sensors.service
           827ms wol.service
           397ms accounts-daemon.service
           336ms systemd-logind.service
           308ms loadcpufreq.service
           295ms irqbalance.service
           292ms ufw.service
           287ms grub-common.service
           274ms ondemand.service
           274ms avahi-daemon.service
           241ms apparmor.service
           231ms pppd-dns.service
           231ms iio-sensor-proxy.service
           226ms rsyslog.service
           222ms snapd.autoimport.service
           217ms thermald.service
           199ms systemd-user-sessions.service
           194ms systemd-udev-trigger.service
           193ms console-setup.service
           192ms alsa-restore.service
           181ms gpu-manager.service
           135ms systemd-modules-load.service
           132ms binfmt-support.service
           127ms upower.service
           103ms keyboard-setup.service
           101ms udisks2.service
            98ms networking.service
            72ms systemd-journald.service
            66ms lightdm.service
            65ms cpufrequtils.service
            49ms systemd-journal-flush.service
            47ms polkitd.service
            46ms systemd-tmpfiles-clean.service
            37ms colord.service
            35ms rc-local.service
            30ms proc-sys-fs-binfmt_misc.mount
            28ms user@1000.service
            28ms resolvconf.service
            23ms kmod-static-nodes.service
            21ms dev-mqueue.mount
            21ms systemd-udevd.service
            21ms dev-disk-by\x2duuid-d4995c8e\x2d3c9e\x2d4fda\x2d80a3\x2dc88e942f6204.swap
            21ms systemd-tmpfiles-setup-dev.service
            20ms plymouth-read-write.service
            20ms sys-kernel-debug.mount
            19ms dns-clean.service
            18ms systemd-tmpfiles-setup.service
            17ms systemd-update-utmp.service
            15ms systemd-random-seed.service
            14ms systemd-remount-fs.service
            11ms systemd-update-utmp-runlevel.service
            11ms systemd-sysctl.service
             9ms dev-hugepages.mount
             9ms systemd-timesyncd.service
             7ms ureadahead-stop.service
             7ms snapd.socket
             6ms setvtrgb.service
             5ms sys-fs-fuse-connections.mount
             5ms rtkit-daemon.service
             3ms plymouth-quit-wait.service
yvan@yvan-maison:~$

Quelle est ton opinion sur l'idée d'essayer de faire en sorte que le service alsa-restore.service se lance à la toute fin du processus de démarrage ?

Dernière modification par ylag (Le 21/08/2017, à 00:01)

grandtoubab · Le 19/08/2017, à 00:34

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

Dernière modification par grandtoubab (Le 19/08/2017, à 09:20)

ylag · Le 19/08/2017, à 12:35

@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+

Dernière modification par ylag (Le 19/08/2017, à 13:01)

ylag · Le 19/08/2017, à 12:59

@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+

Dernière modification par ylag (Le 20/08/2017, à 23:59)

grandtoubab · Le 19/08/2017, à 12:59

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 · Le 19/08/2017, à 13:05

@grandtoubab :

grandtoubab a écrit :

Affaire 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+

Dernière modification par ylag (Le 19/08/2017, à 13:44)

ylag · Le 19/08/2017, à 13:30

@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.

Dernière modification par ylag (Le 21/08/2017, à 00:04)

ylag · Le 19/08/2017, à 16:57

@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+

Dernière modification par ylag (Le 19/08/2017, à 22:05)

grandtoubab · Le 19/08/2017, à 18:08

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

Dernière modification par grandtoubab (Le 19/08/2017, à 18:10)

grandtoubab · Le 20/08/2017, à 13:48

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

Dernière modification par grandtoubab (Le 20/08/2017, à 13:52)

ylag · Le 20/08/2017, à 14:14

@grandtoubab :

Salut,

grandtoubab a écrit :

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

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+

Dernière modification par ylag (Le 21/08/2017, à 00:05)

grandtoubab · Le 20/08/2017, à 14:45

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 · Le 20/08/2017, à 14:59

Salut,

J'avais proposé une manip du genre à jecarpi : https://forum.ubuntu-fr.org/viewtopic.p … #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+++

Dernière modification par ylag (Le 20/08/2017, à 15:04)

grandtoubab · Le 20/08/2017, à 15:36

ylag a écrit :

Salut,
J'avais proposé une manip du genre à jecarpi : https://forum.ubuntu-fr.org/viewtopic.p … #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 · Le 20/08/2017, à 19:38

@grandtoubab :

Salut,

grandtoubab a écrit :

mais 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) ?

Dernière modification par ylag (Le 20/08/2017, à 20:24)

grandtoubab · Le 20/08/2017, à 20:24

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

Dernière modification par grandtoubab (Le 20/08/2017, à 20:33)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 18/08/2017, à 18:18

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

#52 Le 18/08/2017, à 18:29

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

#53 Le 18/08/2017, à 18:44

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

#54 Le 18/08/2017, à 18:48

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

#55 Le 18/08/2017, à 18:51

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

#56 Le 18/08/2017, à 18:59

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

#57 Le 18/08/2017, à 20:16

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

#58 Le 18/08/2017, à 20:30

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

#59 Le 18/08/2017, à 21:52

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

#60 Le 18/08/2017, à 23:20

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

#61 Le 19/08/2017, à 00:34

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

#62 Le 19/08/2017, à 12:35

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

#63 Le 19/08/2017, à 12:59

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

#64 Le 19/08/2017, à 12:59

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

#65 Le 19/08/2017, à 13:05

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

#66 Le 19/08/2017, à 13:30

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

#67 Le 19/08/2017, à 16:57

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

#68 Le 19/08/2017, à 18:08

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

#69 Le 20/08/2017, à 13:48

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

#70 Le 20/08/2017, à 14:14

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

#71 Le 20/08/2017, à 14:45

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

#72 Le 20/08/2017, à 14:59

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

#73 Le 20/08/2017, à 15:36

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

#74 Le 20/08/2017, à 19:38

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

#75 Le 20/08/2017, à 20:24

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

Pied de page des forums