jeanFrancoisHicter htop toutes les 10 ms Quand 1 de mes 4 threads saute à 100 % = xrun Donc, il y a une logique, c'est déjà ça... Reste que ce thread qui saute n'a, a priori, pas de solution : j'ai fait l'essai en faisant tourner Spotify en solo, sans Firefox ou autre, et il semblerait que ce soit Pulseaudio qui soit responsable du saut à 100 %... Mais, un saut qui n'a pas d'explication logique : pourquoi le système roule à 20 % et, d'un seul coup, saute -- un thread, pas tout le CPU -- à 100 % ? 😐 P.S. : Je tourne sur KDE Neon, comme tu peux le lire en signature... 😉
krodelabestiole tu peux éventuellement désactiver pulseaudio. il faut remplacer ; autospawn = yes par autospawn = no dans /etc/pulse/client.conf puis pulseaudio --kill pour arrêter pulseaudio et pulseaudio --start pour le redémarrer.
jeanFrancoisHicter Sauf que si je kill pulseaudio, je n'ai plus de son... Jack ne prend pas la main et pavucontrol est inopérant...
krodelabestiole pavucontrol est une interface graphique pour gérer pulseaudio, donc si tu tues pulseaudio il ne risque pas de marcher. jack est un serveur de son (dédié à la mao), pulseaudio en est un autre (dédié au multimédia et à la lecture à distance). pour la mao on utilise jack, et pas pulseaudio. et pour utiliser jack, historiquement on était obligé d'arrêter pulseaudio sinon ça entrait en conflit vis à vis d'alsa (le driver de la carte son). avec jack sink, pulseaudio se connecte à jack au lieu de se connecter à alsa, donc problème résolu. et donc pulseaudio n'est absolument pas nécessaire au bon fonctionnement de jack (c'est plutôt un obstacle). si tes applications ne sortent plus de son quand tu tues pulseaudio, c'est qu'elles n'utilisent pas jack. pour un navigateur web ou un lecteur multimédia c'est normal. pour une application de MAO c'est plutôt signe qu'elle est mal configurée.
jeanFrancoisHicter Donc, je kill pulseaudio quand je veux utiliser les applis qui utilisent Jack... Okay... Je tiens au courant... Je fais une pause, là 🙂
jeanFrancoisHicter J'ai finalement identifié le processus responsable : wpa_supplicant. En éteignant le wifi, tout fonctionne sans glitch...
