Bonjour,
Depuis quelque temps, quand je lance Audacity, le message suivant
s'affiche :
"There was an error initializing the audio i/o layer. you will not be
able to play or record audio.
Erreur: Host error"
Et effectivement je ne peux écouter mes morceaux favoris.
J'ai donc consulté HardDrake qui propose un petit guide de résolution de
problèmes. Voici la moisson des renseignements recueillis sous sa
direction :
# aumix -q
vol 84, 84, P
pcm 75, 75
speaker 100, 100
line 75, 75, P
mic 100, 100, R
cd 100, 100, P
igain 90, 90
line1 100, 100, P
phin 100, 100, P
video 52, 52, P
Si je kill le processus 2037, le son fonctionne. Mais ce processus est
relancé à chaque redémarrage du pc et je désirerais comprendre comment
cela se fait et éventuellement comment l'empêcher.
Voici encore quelques informations d'ordre général :
Mandrake 9.2
Noyau 2.4.22-21mdk (depuis quelques jours, mais *il me semble* que le
problème décrit se manifestait déjà parfois avant)
Carte son : Creative Labs, model CT4810
Si vous pouviez m'indiquer dans quelle direction chercher...
Si je kill le processus 2037, le son fonctionne. Mais ce processus est relancé à chaque redémarrage du pc et je désirerais comprendre comment cela se fait et éventuellement comment l'empêcher.
Impossible de m'arrêter sur le chemin de la connaissance ;-) Aujourd'hui je découvre parmi les réponses à $ ps U geo : PID TTY STAT TIME COMMAND 2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage - 2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de kde, un menu "système de sons" où j'ai récemment coché la case "Lancer le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre. Ça m'apprendra à cliquer sans savoir pourquoi !
Merci à Flotus, et bonne année à tous avec plein de problèmes passionnants à résoudre. :-)
Si je kill le processus 2037, le son fonctionne. Mais ce processus est
relancé à chaque redémarrage du pc et je désirerais comprendre comment
cela se fait et éventuellement comment l'empêcher.
Impossible de m'arrêter sur le chemin de la connaissance ;-)
Aujourd'hui je découvre parmi les réponses à
$ ps U geo :
PID TTY STAT TIME COMMAND
2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage -
2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de
kde, un menu "système de sons" où j'ai récemment coché la case "Lancer
le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre.
Ça m'apprendra à cliquer sans savoir pourquoi !
Merci à Flotus, et bonne année à tous avec plein de problèmes
passionnants à résoudre. :-)
Si je kill le processus 2037, le son fonctionne. Mais ce processus est relancé à chaque redémarrage du pc et je désirerais comprendre comment cela se fait et éventuellement comment l'empêcher.
Impossible de m'arrêter sur le chemin de la connaissance ;-) Aujourd'hui je découvre parmi les réponses à $ ps U geo : PID TTY STAT TIME COMMAND 2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage - 2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de kde, un menu "système de sons" où j'ai récemment coché la case "Lancer le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre. Ça m'apprendra à cliquer sans savoir pourquoi !
Merci à Flotus, et bonne année à tous avec plein de problèmes passionnants à résoudre. :-)
sans_flotus_spam
Geo Cherchetout wrote:
J'ai oublié de mentionner certains extraits de /var/log/messages recueillis après l'un de mes derniers démarrages :
Dec 31 10:28:20 PIII alsa: succeeded Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-2 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-3 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-4 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-5 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-6 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-7
Dec 31 10:29:46 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:29:46 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:29:47 PIII last message repeated 5 times
Dec 31 10:29:47 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:29:48 PIII last message repeated 4 times
Dec 31 10:29:48 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:29:49 PIII last message repeated 3 times
Qu'est-ce donc que ce module snd-card-1 ? Que faire pour qu'il soit trouvé ? le système regarde si tu as d'autres cartes son (sous Linux, on peut
installer plusieurs cartes sons) ; comme tu n'en as qu'une, il ne trouve pas les autres ... pour la première question, quels sont les droits sur les devices audio ? as-tu créé un groupe "audio" auquel appartiennent les devices et les users ? A+
Geo Cherchetout wrote:
J'ai oublié de mentionner certains extraits de /var/log/messages
recueillis après l'un de mes derniers démarrages :
Dec 31 10:28:20 PIII alsa: succeeded
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-2
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-3
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-4
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-5
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-6
Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-7
Dec 31 10:29:46 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:29:46 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:29:47 PIII last message repeated 5 times
Dec 31 10:29:47 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:29:48 PIII last message repeated 4 times
Dec 31 10:29:48 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:29:49 PIII last message repeated 3 times
Qu'est-ce donc que ce module snd-card-1 ? Que faire pour qu'il soit trouvé
?
le système regarde si tu as d'autres cartes son (sous Linux, on peut
installer plusieurs cartes sons) ; comme tu n'en as qu'une, il ne trouve
pas les autres ...
pour la première question, quels sont les droits sur les devices audio ?
as-tu créé un groupe "audio" auquel appartiennent les devices et les users ?
A+
J'ai oublié de mentionner certains extraits de /var/log/messages recueillis après l'un de mes derniers démarrages :
Dec 31 10:28:20 PIII alsa: succeeded Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-2 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-3 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-4 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-5 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-6 Dec 31 10:28:21 PIII modprobe: modprobe: Can't locate module snd-card-7
Dec 31 10:29:46 PIII modprobe: modprobe: Can't locate module snd-card-1
Dec 31 10:29:46 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:29:47 PIII last message repeated 5 times
Dec 31 10:29:47 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:29:48 PIII last message repeated 4 times
Dec 31 10:29:48 PIII modprobe: modprobe: Can't locate module snd-card-1 Dec 31 10:29:49 PIII last message repeated 3 times
Qu'est-ce donc que ce module snd-card-1 ? Que faire pour qu'il soit trouvé ? le système regarde si tu as d'autres cartes son (sous Linux, on peut
installer plusieurs cartes sons) ; comme tu n'en as qu'une, il ne trouve pas les autres ... pour la première question, quels sont les droits sur les devices audio ? as-tu créé un groupe "audio" auquel appartiennent les devices et les users ? A+
Si je kill le processus 2037, le son fonctionne. Mais ce processus est relancé à chaque redémarrage du pc et je désirerais comprendre comment cela se fait et éventuellement comment l'empêcher.
Impossible de m'arrêter sur le chemin de la connaissance ;-) Aujourd'hui je découvre parmi les réponses à $ ps U geo : PID TTY STAT TIME COMMAND 2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage - 2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de kde, un menu "système de sons" où j'ai récemment coché la case "Lancer le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre. Ça m'apprendra à cliquer sans savoir pourquoi !
Merci à Flotus, et bonne année à tous avec plein de problèmes passionnants à résoudre. :-)
Pour un info une methode moins aleatoire pour ce genre de problem (dev occuppé) est lsof (LiSt Open File).
Si je kill le processus 2037, le son fonctionne. Mais ce processus est
relancé à chaque redémarrage du pc et je désirerais comprendre comment
cela se fait et éventuellement comment l'empêcher.
Impossible de m'arrêter sur le chemin de la connaissance ;-)
Aujourd'hui je découvre parmi les réponses à
$ ps U geo :
PID TTY STAT TIME COMMAND
2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage -
2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de
kde, un menu "système de sons" où j'ai récemment coché la case "Lancer
le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre.
Ça m'apprendra à cliquer sans savoir pourquoi !
Merci à Flotus, et bonne année à tous avec plein de problèmes
passionnants à résoudre. :-)
Pour un info une methode moins aleatoire pour ce genre de problem (dev
occuppé) est lsof (LiSt Open File).
Si je kill le processus 2037, le son fonctionne. Mais ce processus est relancé à chaque redémarrage du pc et je désirerais comprendre comment cela se fait et éventuellement comment l'empêcher.
Impossible de m'arrêter sur le chemin de la connaissance ;-) Aujourd'hui je découvre parmi les réponses à $ ps U geo : PID TTY STAT TIME COMMAND 2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage - 2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de kde, un menu "système de sons" où j'ai récemment coché la case "Lancer le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre. Ça m'apprendra à cliquer sans savoir pourquoi !
Merci à Flotus, et bonne année à tous avec plein de problèmes passionnants à résoudre. :-)
Pour un info une methode moins aleatoire pour ce genre de problem (dev occuppé) est lsof (LiSt Open File).
Si je kill le processus 2037, le son fonctionne. Mais ce processus est relancé à chaque redémarrage du pc et je désirerais comprendre comment cela se fait et éventuellement comment l'empêcher.
Bin fait un 'grep -l -e artsd -f *' après t'être placé dans le répertoire qui lance les scripts de démmarrage (/etc/init.d ou /etc/rc.d)
Impossible de m'arrêter sur le chemin de la connaissance ;-) Aujourd'hui je découvre parmi les réponses à $ ps U geo : PID TTY STAT TIME COMMAND 2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage - 2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de kde, un menu "système de sons" où j'ai récemment coché la case "Lancer le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre. Ça m'apprendra à cliquer sans savoir pourquoi !
C'est le plus gros défaut de KDE quand on veut bidouiller son système, on se retrouve à cliquer sur des zigouiguois un peu au hazard (c'est pas une faute, hazard = danger en engliche) comme sous windows. Même si KDE permet effectivement une transition plus douce quand on est windowsien d'origine.
Il faut que tu comprennes comment fonctionne le système (cf /usr/share/doc) et que tu ailles bidouiller à la main (avec le bout des doigts avec ton vim préféré) les fichiers de configuration qui sont en texte pur et très bien commentés.
Merci à Flotus, et bonne année à tous avec plein de problèmes passionnants à résoudre. :-)
Pour un info une methode moins aleatoire pour ce genre de problem (dev occuppé) est lsof (LiSt Open File).
Oui, mais lsof et fuser ne montre pas qui utilise un dev si on est loggé en user et que c'est root qui utilise le dev.
Il y a un autre problème avec les fichiers sons et notamment ceux de KDE, et j'avais posté ce qui suit il y a une quinzaine de jours et je pense que ça va rentrer dans la FAQ de fcolc:
8<-------------------------------------------------------- J'ai eu un problème avec mon '/dev/audio' qui restait bêtement occupé après que j'ai joué avec la commande 'cat' un fichier '.wav' et j'ai découvert que certains sons doivent être mal formatés.
Exemple: "cat /usr/share/sounds/KDE_Dialog_Disappear.wav > /dev/audio" ne rend pas la main, on est obligé de faire "Ctrl-C" pour récupérer le prompt.
Si on lance cette commande avec un "&" à la fin pour l'exécuter en tâche de fond, alors on récupère la main, mais le /dev/audio reste occupé.
Tout dépend des sons qui sont joués, par exemple: "cat /usr/share/sounds/KDE_Notify.wav > /dev/audio" rend la main et ne bloque pas /dev/audio si on y ajoute un "&".
Piège: Si le script qui fait le 'cat' vers '/dev/audio' avec un "mauvais" '.wav' est exécuté en 'root' et bloque donc '/dev/audio' et qu'ensuite on lance la commande 'fuser' ou 'lsof' en user, on ne voit pas le programme ('cat' en l'occurence) qui bloque '/dev/audio', on croit donc à un bug incompréhensible du système. 8<--------------------------------------------------------
Si je kill le processus 2037, le son fonctionne. Mais ce processus est
relancé à chaque redémarrage du pc et je désirerais comprendre comment
cela se fait et éventuellement comment l'empêcher.
Bin fait un 'grep -l -e artsd -f *' après t'être placé dans le
répertoire qui lance les scripts de démmarrage (/etc/init.d ou
/etc/rc.d)
Impossible de m'arrêter sur le chemin de la connaissance ;-)
Aujourd'hui je découvre parmi les réponses à
$ ps U geo :
PID TTY STAT TIME COMMAND
2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage -
2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de
kde, un menu "système de sons" où j'ai récemment coché la case "Lancer
le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre.
Ça m'apprendra à cliquer sans savoir pourquoi !
C'est le plus gros défaut de KDE quand on veut bidouiller son système,
on se retrouve à cliquer sur des zigouiguois un peu au hazard (c'est pas
une faute, hazard = danger en engliche) comme sous windows. Même si KDE
permet effectivement une transition plus douce quand on est windowsien
d'origine.
Il faut que tu comprennes comment fonctionne le système (cf
/usr/share/doc) et que tu ailles bidouiller à la main (avec le bout des
doigts avec ton vim préféré) les fichiers de configuration qui sont en
texte pur et très bien commentés.
Merci à Flotus, et bonne année à tous avec plein de problèmes
passionnants à résoudre. :-)
Pour un info une methode moins aleatoire pour ce genre de problem (dev
occuppé) est lsof (LiSt Open File).
Oui, mais lsof et fuser ne montre pas qui utilise un dev si on est loggé
en user et que c'est root qui utilise le dev.
Il y a un autre problème avec les fichiers sons et notamment ceux de
KDE, et j'avais posté ce qui suit il y a une quinzaine de jours et je
pense que ça va rentrer dans la FAQ de fcolc:
8<--------------------------------------------------------
J'ai eu un problème avec mon '/dev/audio' qui restait bêtement occupé
après que j'ai joué avec la commande 'cat' un fichier '.wav' et j'ai
découvert que certains sons doivent être mal formatés.
Exemple:
"cat /usr/share/sounds/KDE_Dialog_Disappear.wav > /dev/audio"
ne rend pas la main, on est obligé de faire "Ctrl-C" pour récupérer le
prompt.
Si on lance cette commande avec un "&" à la fin pour l'exécuter en tâche
de fond, alors on récupère la main, mais le /dev/audio reste occupé.
Tout dépend des sons qui sont joués, par exemple:
"cat /usr/share/sounds/KDE_Notify.wav > /dev/audio"
rend la main et ne bloque pas /dev/audio si on y ajoute un "&".
Piège:
Si le script qui fait le 'cat' vers '/dev/audio' avec un "mauvais"
'.wav' est exécuté en 'root' et bloque donc '/dev/audio' et qu'ensuite
on lance la commande 'fuser' ou 'lsof' en user, on ne voit pas le
programme ('cat' en l'occurence) qui bloque '/dev/audio', on croit donc
à un bug incompréhensible du système.
8<--------------------------------------------------------
Si je kill le processus 2037, le son fonctionne. Mais ce processus est relancé à chaque redémarrage du pc et je désirerais comprendre comment cela se fait et éventuellement comment l'empêcher.
Bin fait un 'grep -l -e artsd -f *' après t'être placé dans le répertoire qui lance les scripts de démmarrage (/etc/init.d ou /etc/rc.d)
Impossible de m'arrêter sur le chemin de la connaissance ;-) Aujourd'hui je découvre parmi les réponses à $ ps U geo : PID TTY STAT TIME COMMAND 2037 ? S 0:13 /usr/bin/artsd -F 10 -S 4096 -d -s 8 -m artsmessage - 2039 ? S 0:00 kdeinit: knotify
Et, de fil en aiguille, parmi les méandres du labyrinthe des menus de kde, un menu "système de sons" où j'ai récemment coché la case "Lancer le serveur de son aRts au démarrage de kde".
Je décoche la case et tout rentre dans l'ordre. Ça m'apprendra à cliquer sans savoir pourquoi !
C'est le plus gros défaut de KDE quand on veut bidouiller son système, on se retrouve à cliquer sur des zigouiguois un peu au hazard (c'est pas une faute, hazard = danger en engliche) comme sous windows. Même si KDE permet effectivement une transition plus douce quand on est windowsien d'origine.
Il faut que tu comprennes comment fonctionne le système (cf /usr/share/doc) et que tu ailles bidouiller à la main (avec le bout des doigts avec ton vim préféré) les fichiers de configuration qui sont en texte pur et très bien commentés.
Merci à Flotus, et bonne année à tous avec plein de problèmes passionnants à résoudre. :-)
Pour un info une methode moins aleatoire pour ce genre de problem (dev occuppé) est lsof (LiSt Open File).
Oui, mais lsof et fuser ne montre pas qui utilise un dev si on est loggé en user et que c'est root qui utilise le dev.
Il y a un autre problème avec les fichiers sons et notamment ceux de KDE, et j'avais posté ce qui suit il y a une quinzaine de jours et je pense que ça va rentrer dans la FAQ de fcolc:
8<-------------------------------------------------------- J'ai eu un problème avec mon '/dev/audio' qui restait bêtement occupé après que j'ai joué avec la commande 'cat' un fichier '.wav' et j'ai découvert que certains sons doivent être mal formatés.
Exemple: "cat /usr/share/sounds/KDE_Dialog_Disappear.wav > /dev/audio" ne rend pas la main, on est obligé de faire "Ctrl-C" pour récupérer le prompt.
Si on lance cette commande avec un "&" à la fin pour l'exécuter en tâche de fond, alors on récupère la main, mais le /dev/audio reste occupé.
Tout dépend des sons qui sont joués, par exemple: "cat /usr/share/sounds/KDE_Notify.wav > /dev/audio" rend la main et ne bloque pas /dev/audio si on y ajoute un "&".
Piège: Si le script qui fait le 'cat' vers '/dev/audio' avec un "mauvais" '.wav' est exécuté en 'root' et bloque donc '/dev/audio' et qu'ensuite on lance la commande 'fuser' ou 'lsof' en user, on ne voit pas le programme ('cat' en l'occurence) qui bloque '/dev/audio', on croit donc à un bug incompréhensible du système. 8<--------------------------------------------------------
