Salut à tous,
Albert :
Pour clarifier les choses que j'ai un peut-être un peu embrouillées,
j'ai répondu à ce fil de msg parce que je rencontre des problèmes
similaires, et ayant suivi la piste que t'avais soumise Thomas, j'ai
voulu te faire profiter de mes essais tout en demandant plus d'infos à
thomas.
Vu les commentaires ('rien') que tu as fait quant aux commandes que je
t'avais rapportées, je me permet de te les expliciter un peu, mais
peut-être devrais-tu lire des infos quant à la ligne de commande/console
pour te familiariser
(http://formation-debian.via.ecp.fr/debuter-console.html)
L'idée étant d'auditer les états des modules de noyau chargés ('lsmod')
en lançant des commandes lorsque le son marche et lorsque le son ne
marche plus, puis de comparer leur resultat respectif ('diff') afin de
degager des pistes de resolution, notamment activer/desactiver/reactiver
des modules ('modprobe').
Lorsque tu fais la commande "lsmod |sort -n > modules_son_on" il s'agit
de lister les modules chargés et d'écrire cette liste dans un fichier
nommé "modules_son_on" dans le répertoire en cours (que tu peux savoir
en lançant "pwd")
Ceci étant fait lorsque le son marche ('on')
Puis lorsque le son ne marche plus ('off') tu refais la commande mais en
écrivant le résultat cette fois dans le fichier "modules_son_off"
enfin tu compares ces résultats en comparant les 2 fichiers générés (ils
doivent être dans le même répertoire) : "diff modules_son_off
modules_son_on"
Les 2 premières commandes (lorsque le son marche puis ne marche plus)
écrivant le résultat dans un fichier, il est normal que la ligne de
commande ne te retourne 'rien'
Par contre les différences entre les deux fichiers (puisque cela n'a pas
été redirigé vers un fichier : c'est la signification de l'opérateur
'>') sont retournées directement dans la console, donc si cela ne te
renvoie rien c'est qu'il n'y a pas de différences (ou as-tu lancé les
commandes sans attendre que le son ne marche plus ?)
bref, peut-être que cette armada de commandes ne sont pas adaptées à ton
problème, essayes plutôt la piste relevée par thomas :
N'y a-t-il pas de channel muet quand tu fais alsamixer ?
"alsamixer" permettant (en console,équivalent à faire un bouton droit
sur l'icône de volume de la barr des tâches + "Ouvrir le contrôleur de
volume" ) de régler le niveau sonore des différents canaux. Il s'agit de
voir s'il n'y en a pas un qui est 'muté' càd en sourdine.
+ pour répondre à cette liste publique et non pas à l'auteur d'une
réponse avec le bouton 'répondre à', il faut envoyer ton mel à l'adresse
de la liste : debian-user-french@lists.debian.org, en essayant de ne
citer qu'une partie ciblée du post précédent plutôt qu'entièrement
...comme le disait claudux avec poésie peux-être devrais-tu lire la faq
de la liste :
http://www.debian.org/MailingLists/index.fr.html#codeofconduct
voilà désolé de t'avoir peut-être embrouillé et en espérant ne pas
t'avoir trop infantilisé (et démystifié la belle poésie de claudux !)-
cordialement - bon courage
Thomas:
merci pour la piste ac97. Les modules snd_ac97_codec et ac97_bus son
chargés par mon modem rtc. pas réussi à les désactiver malgré des
blacklist dans /etc/modprobe.d. Une connexion à un autre utilisateur
puis fermeture résolvant le problème, je ne suis pas sûr que ça vienne
de là mais plutôt de pulseaudio...étant en sid, je m'en contenterai donc
pour le moment et je re-tenterai des trucs dès la prochaine version de pa.
sputnik:
super ta checklist alsa, je met de côté. Maintenant ayant réussi à avoir
pulseaudio 'presque' stable, j'ose même plus à re-toucher ni à la config
alsa ou oss...
re-merci à tous
Antoine Y