Re: Délai de 25 secondes
Salut, Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type. Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que je venais de mettre à jour. Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et Xdaliclock. Le problème est croissant et menace de devenir handicapant en Debian 13. Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol. Quelque chose qui rend mon installation peu courante, c'est que pendant l'install je décoche toutes les cases liées à des gestionnaires de fenêtres, et une fois l'install terminée j'installe le minimum (fvwm et ses dépendances). D'habitude, quand on décoche toutes ces cases, c'est pour un serveur (qui ne lancera jamais xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes). De la sorte, il est probable que je n'installe pas un package qui est standard chez les autres utilisateurs et qui s'avère utile pour certains logiciels graphiques (quoique pas indispensable puisque ces logiciels finissent par se lancer). Sinon, un rapport de bogue sur https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait être utile. C'est vrai qu'un rapport de bug pourrait servir. Peut-être plus avec reportbug toutefois, si c'est bien un package qui me manque ; il n'y aurait alors qu'une simple dépendance à ajouter. Pour ma part, je cherche des contributeurs pour le moteur d'inférences http://refpersys.org/ Ça a l'air intéressant ; bonne chance ! Si tu as la flemme de débugger, j'imagine que tu as actuellement pulseaudio d'installé. Tu pourrais le retirer au profit de pipewire-pulse et voir si ça fonctionne mieux. À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication des endroits où le délai se manifeste qui m'inquiète. En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle socket/autre il poll. Ben ça donne ça: ~> ls -l /proc/$(pidof pavucontrol)/fd/11 lrwx-- 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]' Seb.
Re: Activer l'encodage matériel dans OBS studio
Merci. Je suis sous Debian 11 (Oldstable) J'ai une carte-mère MSI X470 Gaming Plus _,met$gg. ,g$$$P. ,g$$P" """Y$$.". OS: Debian GNU/Linux 11 (bullseye) x86_64 ,$$P' `$$$. Host: MS-7B79 2.0 ',$$P ,ggs. `$$b: Kernel: 5.10.0-26-amd64 `d$$' ,$P"' . $$$ Uptime: 1 hour, 57 mins $$P d$' , $$P Packages: 2266 (dpkg) $$: $$. - ,d$$' Shell: bash 5.1.4 $$; Y$b._ _,d$P' Resolution: 2560x1440 Y$$. `.`"YP"' DE: GNOME 3.38.6 `$$b "-.__ WM: Mutter `Y$$ WM Theme: Adwaita `Y$$. Theme: Adwaita [GTK2/3] `$$b. Icons: Adwaita [GTK2/3] `Y$$b. Terminal: gnome-terminal `"Y$b._ CPU: AMD Ryzen 7 3700X (16) @ 3.600GHz `""" GPU: AMD ATI Radeon RX 470/480/570/570X/580/580X/590 Memory: 2924MiB / 32083MiB Mon lspci donne ça : 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 5 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 6 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 7 01:00.0 Non-Volatile memory controller: Phison Electronics Corporation E12 NVMe Controller (rev 01) 03:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43d0 (rev 01) 03:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01) 03:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge (rev 01) 20:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 20:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 20:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 20:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 20:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 20:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 22:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 26:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 27:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7) 27:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] 28:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function 29:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP 29:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPC
Activer l'encodage matériel dans OBS studio
Bonjour tout le monde, J'ai une assez bonne carte graphique AMD, mais je ne peux pas vraiment en profiter sous Debian, car l'encodage matériel n'est pas une option avec Debian. J'obtiens toujours des vidéos floues. Ça semble être la même chose avec les puces graphiques intégrées de chez Intel. C'est tellement frustrant, car je n'ai pu jusqu'ici utiliser OBS-studio avec l'encodage matériel, et faire une capture vidéo correcte, que sous Windaube. Comment obtenir une bonne qualité d'image en capture vidéo sous Debian ? L'encodage matériel est-il possible sous Debian ? Mes propres recherches sur la toile n'ont rien donné jusque là. Par avance, merci pour vos réponses. Librement, Firenze
Re: Debian Login
On Thursday 09 November 2023 12:58:11Tiago Madeira wrote: > Quand j ai fait le lspci ça m as mis ça : Image jointe illisible. Préférer un copier coller. > Le mer. 8 nov. 2023 20:20, ajh-valmer a écrit : > > On Wednesday 08 November 2023 14:06:12 Tiago Madeira wrote: > > > Hier j ai installer debian12 netinst sur pc bureautique je le lance > > ça me mets error Devian login je me mets en root et je fait apt-get > > install gnome ça ne fonctionne je n'ai pas d'interface graphique > > aidez moi > > le pilote de la carte vidéo est-il installé ? > > Taper lspci en mode console pour voir le modèle de la carte, > > puis la chercher chez le fabricant ou les dépôts Debian. > > Après on y verra plus clair. > > # apt-get install gnome , est-il suffisant. > > Taper alors : > > # apt-cache search gnome > > pour indiquer le ou les bons paquets gnome à installer. > > Allez, au boulot ! :-))
Re: Délai de 25 secondes
Seb wrote on 09/11/2023 at 11:34:11+0100: > Bonjour ! > > > J'ai installé hier une Debian 12 en remplacement d'une Debian plus > ancienne. C'est une installation à partir de zéro, pas une mise > à jour. > > Mon gestionnaire de fenêtres est fvwm. > > Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule > 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian > précédente, j'avais remarqué le même délai avec firefox depuis > quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou > xdaliclock ait posé le même problème dans la Debian que j'utilisais > précédemment. > > Les autres programmes s'ouvrent sans délai (gimp, brave-browser, > okular, etc.). > > Quand j'appelle "strace pavucontrol", les messages cessent de défiler > en arrivant à la dernière des lignes copiées-collées ci-dessous : > > [...] > eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11 > futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN > (Resource temporarily unavailable) > futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0 > write(10, "\1\0\0\0\0\0\0\0", 8)= 8 > futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1 > poll([{fd=11, events=POLLIN}], 1, 25000 > > Sitôt le délai (25000) passé, pavucontrol s'ouvre. > > Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins > d'une direction dans laquelle chercher ? Si tu as la flemme de débugger, j'imagine que tu as actuellement pulseaudio d'installé. Tu pourrais le retirer au profit de pipewire-pulse et voir si ça fonctionne mieux. En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle socket/autre il poll. -- PEB signature.asc Description: PGP signature
Re: Délai de 25 secondes
On 11/9/23 15:12, Seb wrote: Bonjour, poll([{fd=11, events=POLLIN}], 1, 25000 Là il attend un évènement sur le file descripteur 11, il faudrait repérer au dessus un appel open (ou nom approchant) que retourne 11 pour voir à quelle ressource ça correspond J'ai redirigé la sortie de strace vers un fichier "trace". Ensuite: ~/temp> egrep 'poll.*fd=11|^open.*= 11' trace | cat -n 1 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 2 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 3 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 4 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 5 poll([{fd=11, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) 6 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache", O_RDONLY) = 11 7 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11 8 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so", O_RDONLY|O_CLOEXEC) = 11 9 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so", O_RDONLY|O_CLOEXEC) = 11 [...] C'est le "poll" de la ligne 5 qui bloque. Je ne vois donc pas d'openat renvoyant 11 dans les lignes qui le précèdent. Je devine qu'un processus (j'ignore lequel) a appellé eventfd, qui est très utile mais spécifique à Linux: https://man7.org/linux/man-pages/man2/eventfd.2.html Peut-être qu'il serait utile de télécharger le code source de pavucontrol https://freedesktop.org/software/pulseaudio/pavucontrol/ et d'y chercher les appels à eventfd. Sinon, un rapport de bogue sur https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait être utile. ls -l /proc/$(pidof pavucontrol)/fd Cela donne, pendant le chargement de pavucontrol : ~> ls -l /proc/$(pidof pavucontrol)/fd total 0 lrwx-- 1 seb seb 64 Nov 9 16:07 0 -> /dev/pts/11 lrwx-- 1 seb seb 64 Nov 9 16:07 1 -> /dev/pts/11 lrwx-- 1 seb seb 64 Nov 9 16:07 10 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 11 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 2 -> /dev/pts/11 lrwx-- 1 seb seb 64 Nov 9 16:06 3 -> 'socket:[443606]' lrwx-- 1 seb seb 64 Nov 9 16:07 4 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 5 -> 'socket:[444861]' lrwx-- 1 seb seb 64 Nov 9 16:07 6 -> 'socket:[440203]' lrwx-- 1 seb seb 64 Nov 9 16:07 7 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 8 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 9 -> 'socket:[444862]' man proc a quelques infos sur "anon_inode:[eventfd]", mais ça ne m'avance pas beaucoup : For file descriptors that have no corresponding inode (e.g., file descriptors produced by bpf(2), epoll_create(2), eventfd(2), inotify_init(2), perf_event_open(2), signalfd(2), timerfd_create(2), and userfaultfd(2)), the entry will be a sym- bolic link with contents of the form anon_inode:file-type In many cases (but not all), the file-type is surrounded by square brackets. For example, an epoll file descriptor will have a symbolic link whose content is the string anon_inode:[eventpoll]. man 2 eventfd parle d'un mécanisme d'attente : eventfd() creates an "eventfd object" that can be used as an event wait/notify mechanism by user-space applications, and by the kernel to notify user-space applications of events. Cela ne m'avance guère. Quelqu'un sait-il donner du sens à tout cela ? Pour ma part, je cherche des contributeurs pour le moteur d'inférences http://refpersys.org/ (avec code en https://github.com/RefPerSys/RefPerSys/ ) Dans quelque temps (j'espère quelques mois) RefPerSys pourrait aider à chasser ce genre de bogue. Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Délai de 25 secondes
Bonjour, poll([{fd=11, events=POLLIN}], 1, 25000 Là il attend un évènement sur le file descripteur 11, il faudrait repérer au dessus un appel open (ou nom approchant) que retourne 11 pour voir à quelle ressource ça correspond J'ai redirigé la sortie de strace vers un fichier "trace". Ensuite: ~/temp> egrep 'poll.*fd=11|^open.*= 11' trace | cat -n 1 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 2 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 3 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 4 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 5 poll([{fd=11, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) 6 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache", O_RDONLY) = 11 7 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11 8 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so", O_RDONLY|O_CLOEXEC) = 11 9 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so", O_RDONLY|O_CLOEXEC) = 11 [...] C'est le "poll" de la ligne 5 qui bloque. Je ne vois donc pas d'openat renvoyant 11 dans les lignes qui le précèdent. ls -l /proc/$(pidof pavucontrol)/fd Cela donne, pendant le chargement de pavucontrol : ~> ls -l /proc/$(pidof pavucontrol)/fd total 0 lrwx-- 1 seb seb 64 Nov 9 16:07 0 -> /dev/pts/11 lrwx-- 1 seb seb 64 Nov 9 16:07 1 -> /dev/pts/11 lrwx-- 1 seb seb 64 Nov 9 16:07 10 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 11 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 2 -> /dev/pts/11 lrwx-- 1 seb seb 64 Nov 9 16:06 3 -> 'socket:[443606]' lrwx-- 1 seb seb 64 Nov 9 16:07 4 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 5 -> 'socket:[444861]' lrwx-- 1 seb seb 64 Nov 9 16:07 6 -> 'socket:[440203]' lrwx-- 1 seb seb 64 Nov 9 16:07 7 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 8 -> 'anon_inode:[eventfd]' lrwx-- 1 seb seb 64 Nov 9 16:07 9 -> 'socket:[444862]' man proc a quelques infos sur "anon_inode:[eventfd]", mais ça ne m'avance pas beaucoup : For file descriptors that have no corresponding inode (e.g., filedescriptors produced by bpf(2), epoll_create(2), eventfd(2), inotify_init(2), perf_event_open(2), signalfd(2), timerfd_create(2), and userfaultfd(2)), the entry will be a sym- bolic link with contents of the form anon_inode:file-type In many cases (but not all), the file-type is surrounded by square brackets. For example, an epoll file descriptor will have a symbolic link whose content is the string anon_inode:[eventpoll]. man 2 eventfd parle d'un mécanisme d'attente : eventfd() creates an "eventfd object" that can be used as an event wait/notify mechanism by user-space applications, and by the kernel to notify user-space applications of events. Cela ne m'avance guère. Quelqu'un sait-il donner du sens à tout cela ? Ou pense à une piste complètement différente pour donner sens à ces 25 secondes d'attente ? Merci ! Seb.
Re: Délai de 25 secondes
Bonjour, Le 2023-11-09 12:59, Erwan David a écrit : Le 09/11/2023 à 11:34, Seb a écrit : poll([{fd=11, events=POLLIN}], 1, 25000 Sitôt le délai (25000) passé, pavucontrol s'ouvre. Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ? Là il attend un évènement sur le file descripteur 11, il faudrait repérer au dessus un appel open (ou nom approchant) que retourne 11 pour voir à quelle ressource ça correspond On doit pouvoir le trouver aussi en lançant cette commande : ls -l /proc/$(pidof pavucontrol)/fd À condition qu'il n'y ait qu'un seul pavucontrol en fonctionnement. Sébastien
Re: Délai de 25 secondes
Le 09/11/2023 à 11:34, Seb a écrit : Bonjour ! J'ai installé hier une Debian 12 en remplacement d'une Debian plus ancienne. C'est une installation à partir de zéro, pas une mise à jour. Mon gestionnaire de fenêtres est fvwm. Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment. Les autres programmes s'ouvrent sans délai (gimp, brave-browser, okular, etc.). Quand j'appelle "strace pavucontrol", les messages cessent de défiler en arrivant à la dernière des lignes copiées-collées ci-dessous : [...] eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11 futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0 write(10, "\1\0\0\0\0\0\0\0", 8) = 8 futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1 poll([{fd=11, events=POLLIN}], 1, 25000 Sitôt le délai (25000) passé, pavucontrol s'ouvre. Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ? Merci pour vos conseils ! Seb. Là il attend un évènement sur le file descripteur 11, il faudrait repérer au dessus un appel open (ou nom approchant) que retourne 11 pour voir à quelle ressource ça correspond
Délai de 25 secondes
Bonjour ! J'ai installé hier une Debian 12 en remplacement d'une Debian plus ancienne. C'est une installation à partir de zéro, pas une mise à jour. Mon gestionnaire de fenêtres est fvwm. Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment. Les autres programmes s'ouvrent sans délai (gimp, brave-browser, okular, etc.). Quand j'appelle "strace pavucontrol", les messages cessent de défiler en arrivant à la dernière des lignes copiées-collées ci-dessous : [...] eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11 futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0 write(10, "\1\0\0\0\0\0\0\0", 8)= 8 futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1 poll([{fd=11, events=POLLIN}], 1, 25000 Sitôt le délai (25000) passé, pavucontrol s'ouvre. Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ? Merci pour vos conseils ! Seb.