Re: Plus de son
- Mail original -
> De: "benoit"
> À: "liste.debian"
> Envoyé: Samedi 22 Octobre 2022 02:05:50
> Objet: Plus de son
> Bonjour à toutes et tous,
> Depuis quelque temps, je n'ai plus de son sur une debian testing.
> Quand j'utilise pavucontrol , sur l'onglet "Périphérique de sortie"
> je vois le curseur bouger au rythme du son, mais rien d'audible.
> Le bouton sourdine est bien désactivé.
> Dans alsamixer au démarrage le master est sur 0, si je le monte et
> que je quitte il est à nouveau sur 0 au démarrage suivant.
> Je ne sais pas comment diagnostiquer le problème
> Merci d'avance
> --
> Benoit
Bonjour Benoit,
Il y a peu de temps, j'ai eu ce problème de son comme toi
et un ami m'a conseillé de changer de "serveur de son" et
comme j'ai du fromage blanc dans la tête, je ne sais plus
lequel est en fonction...
Voici la page qui pourra t'aider :
https://wiki.debian.org/Sound
Maintenant, j'ai de nouveau la mémoire à jour, et
je te conseille de basculer sur Pipewire, et voici
le lien pointant sur la documentation :
https://wiki.debian.org/PipeWire
activer Pipewire :
https://trendoceans.com/install-pipewire-on-debian-11/
article sur phoronix traitant du sujet :
https://www.phoronix.com/news/Debian-12-PipeWire
à titre d'info, voici la liste des paquets installés ainsi
que les versions actuellement disponibles :
dpkg -l |awk '/pipewire/ {print $2,$3}'
gstreamer1.0-pipewire:amd64 0.3.59-1+b1
libpipewire-0.3-0:amd64 0.3.59-1+b1
libpipewire-0.3-common 0.3.59-1
libpipewire-0.3-dev:amd64 0.3.59-1+b1
libpipewire-0.3-modules:amd64 0.3.59-1+b1
pipewire:amd64 0.3.59-1+b1
pipewire-alsa:amd64 0.3.59-1+b1
pipewire-bin 0.3.59-1+b1
pipewire-jack:amd64 0.3.59-1+b1
pipewire-media-session 0.4.1-4+b1
pipewire-pulse 0.3.59-1+b1
Merci pour ton aimable participation sur la liste
Bien à toi
Bernard
Plus de son
Bonjour à toutes et tous, Depuis quelque temps, je n'ai plus de son sur une debian testing. Quand j'utilise pavucontrol, sur l'onglet "Périphérique de sortie" je vois le curseur bouger au rythme du son, mais rien d'audible. Le bouton sourdine est bien désactivé. Dans alsamixer au démarrage le master est sur 0, si je le monte et que je quitte il est à nouveau sur 0 au démarrage suivant. Je ne sais pas comment diagnostiquer le problème Merci d'avance -- Benoit Envoyé avec la messagerie sécurisée [Proton Mail](https://proton.me/).
Re: Comment éteindre un serveur proprement pour permettre le redémarrage automatique ?
Olivier a écrit : > Dans la documentation Eaton, je découvre le paramètre Redémarrage > forcé, qui activé, me semble bien correspondre à l'exigence C Ça m'intéresse. Où as-tu trouvé cette information ? Pour ma part, je n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Comment éteindre un serveur proprement pour permettre le redémarrage automatique ?
Dans la documentation Eaton, je découvre le paramètre Redémarrage forcé, qui activé, me semble bien correspondre à l'exigence C "Si le réseau est rétabli pendant une séquence d'arrêt : - s'il est activé, la séquence d'arrêt se termine et attend 10 secondes avant le redémarrage - s'il est désactivé, la séquence d'arrêt ne se termine pas et le redémarrage a lieu immédiatement." Le ven. 21 oct. 2022 à 10:36, Olivier a écrit : > > Côté serveur, je pense utiliser la combinaison "After Power Failure > valorisée à StayOn /arrêt par Poweroff". > Pour éteindre mon serveur, il faut lui demander de s'arrêter puis > quelques secondes après lui couper sa prise de courant. > Pour le remettre en service, il faut et il suffit "d'allumer" sa prise > de courant. > > Côté onduleur, il me faudrait un onduleur, outre ses qualités propres > (puissance, facilité d'entretien des batteries, ...): > A- qui sache immédiatement notifier un arrêt du courant en amont > B- qui sache notifier avec un certain retard un rétablissement du > courant en amont (*) > C- qui sache alerter un serveur quand son niveau de batterie passe > sous un certain seuil et sache arrêter des prises de courant en aval, > un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas > été reçue ou si courant en amont est revenu entre temps) > D- qui sache rétablir des prises de courant en aval quand le courant > en amont est revenu et quand la batterie est au dessus d'un certain > seuil. > > Avec une interface Ethernet sur l'onduleur, les notifications > pourraient s'opérer par courriel et les alertes par SNMP ou autre > (HTTP ?). Il resterai à vérifier que les exigences ci dessus soient > satisfaites. > La A me parait facile à satisfaire. > La B n'est pas si importante que cela. > La C et la D me paraissent difficile à lire sur une datasheet. > Peut-être qu'en consultant un manuel ? > > (*) Si je n'ai pas de réseau hors bande, il est probable que les > moyens de transmissions des notifications ne soient pas encore > rétablis quand le courant en amont vient juste de se rétablir > > > Le jeu. 20 oct. 2022 à 21:16, Basile Starynkevitch > a écrit : > > > > > > On 20/10/2022 21:08, Th.A.C wrote: > > > > > > > > > Si tu peux exécuter une commande avant, un 'sync' devrait déja > > > améliorer la situation. > > > Il est peut-être possible de forcer le système à vider ses caches très > > > régulièrement, mais ce n'est clairement pas propre. > > > > > > > > Pourquoi ne serait-ce pas propre? > > > > > > Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous > > licence GPLv3+) qui appelle sync périodiquement: > > > > https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c > > > > > > (et je cherche des partenaires intéressés par un consortium > > HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique > > RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel > > aussi au bureau, CEA LIST, en basile.starynkevi...@cea.fr ) > > > > > > -- > > Basile Starynkevitch > > (only mine opinions / les opinions sont miennes uniquement) > > 92340 Bourg-la-Reine, France > > web page: starynkevitch.net/Basile/ > >
Re: Comment éteindre un serveur proprement pour permettre le redémarrage automatique ?
Côté serveur, je pense utiliser la combinaison "After Power Failure valorisée à StayOn /arrêt par Poweroff". Pour éteindre mon serveur, il faut lui demander de s'arrêter puis quelques secondes après lui couper sa prise de courant. Pour le remettre en service, il faut et il suffit "d'allumer" sa prise de courant. Côté onduleur, il me faudrait un onduleur, outre ses qualités propres (puissance, facilité d'entretien des batteries, ...): A- qui sache immédiatement notifier un arrêt du courant en amont B- qui sache notifier avec un certain retard un rétablissement du courant en amont (*) C- qui sache alerter un serveur quand son niveau de batterie passe sous un certain seuil et sache arrêter des prises de courant en aval, un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas été reçue ou si courant en amont est revenu entre temps) D- qui sache rétablir des prises de courant en aval quand le courant en amont est revenu et quand la batterie est au dessus d'un certain seuil. Avec une interface Ethernet sur l'onduleur, les notifications pourraient s'opérer par courriel et les alertes par SNMP ou autre (HTTP ?). Il resterai à vérifier que les exigences ci dessus soient satisfaites. La A me parait facile à satisfaire. La B n'est pas si importante que cela. La C et la D me paraissent difficile à lire sur une datasheet. Peut-être qu'en consultant un manuel ? (*) Si je n'ai pas de réseau hors bande, il est probable que les moyens de transmissions des notifications ne soient pas encore rétablis quand le courant en amont vient juste de se rétablir Le jeu. 20 oct. 2022 à 21:16, Basile Starynkevitch a écrit : > > > On 20/10/2022 21:08, Th.A.C wrote: > > > > > > Si tu peux exécuter une commande avant, un 'sync' devrait déja > > améliorer la situation. > > Il est peut-être possible de forcer le système à vider ses caches très > > régulièrement, mais ce n'est clairement pas propre. > > > > Pourquoi ne serait-ce pas propre? > > > Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous > licence GPLv3+) qui appelle sync périodiquement: > > https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c > > > (et je cherche des partenaires intéressés par un consortium > HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique > RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel > aussi au bureau, CEA LIST, en basile.starynkevi...@cea.fr ) > > > -- > Basile Starynkevitch > (only mine opinions / les opinions sont miennes uniquement) > 92340 Bourg-la-Reine, France > web page: starynkevitch.net/Basile/ >
Re: MTU avec OpenVPN
On 21/10/2022 09:55, Olivier wrote: C'est probablement la bonne explication ! Merci de l'avoir fournie. Pour bien faire, il me faudrait maintenant un moyen pour déterminer la taille des informations transmises ;-) La commande ip -s link affiche le nombre d'octets transmis (reçus ou émis) sur chaque interface réseau. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: MTU avec OpenVPN
C'est probablement la bonne explication ! Merci de l'avoir fournie. Pour bien faire, il me faudrait maintenant un moyen pour déterminer la taille des informations transmises ;-) mais c'est une autre histoire. Merci à tous. Le jeu. 20 oct. 2022 à 20:19, Th.A.C a écrit : > > > > Le 20/10/2022 à 18:02, Olivier a écrit : > > L'existence du MTU ne me choque pas: je pense avoir bien compris > > l'origine de cette limite. > > Ce qui m'étonne que la valeur mesuré soit la même dans les deux cas. > > > > J'aurai imagine qu'OpenVPN ajoute un encapsulage qui diminue la valeur > > du MTU quand j'emprunte le VPN. > > Or il se trouve que non. > > la MTU n'est pas la taille des informations transmises dans un paquet, > mais la taille du paquet lui-même. > > On pourrait comparer ca à un wagon dont la taille est la MTU. > La quantité totale des données est le wagon. > Les données utiles sont à l'intérieur 'encapsulées'(ou pas) par openvpn. > > > OpenVPN n'a donc aucune raison de diminuer la MTU, d'autant que ca a > tendance à réduire la vitesse globale de transmission et que ce n'est > pas du tout son rôle. >
