Lors du démarrage, j'ai un exécutable "Music" dans "/etc/init.d" qui me
lance le programme mpg123 sur un mp3. Et ça marche bien, je l'entend.
Je me loggue en user et dans un xterm je fais "mpg123 /mnt/MP3/ACDC_* &"
Pas de pb, ça marche...
Au bout d'une heure ou deux, il a fini et je veux le relancer, par
exemple avec : "mpg123 /mnt/MP3/ZZ_Top_83_Eliminator_* &" et là il me
dit: "Can't open /dev/dsp"
Je me logge en root dans un xterm et je lance "/etc/init.d/Music" et il
dit la même chose !
/dev/dsp, /dev/audio et /dev/mixer sont "crw-rw-rw- 1 root audio" et mon
user est dans le group audio
Le "Sound Card Support" est compilé en dur dans le noyau ainsi que le
support du circuit "SiS 7012" (noyau 2.4.19 recompilé à la maison avec
sources de ftp.kernel.org)
un "# fuser -av /dev/audio" me montre que personne ne bloque le son
(pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
--
Hugo NPN -<°o))
Ce programme ne gère pas le "groupe wheel" utilisé pour restreindre
l'accès par su au compte Super-Utilisateur, car il pourrait aider des
administrateurs systèmes fascistes à disposer d'un pouvoir incontrôlé
sur les autres utilisateurs. (man su)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
tatane
On Sun, 07 Dec 2003 00:31:04 +0100, Hugolino wrote:
Salut,
Lors du démarrage, j'ai un exécutable "Music" dans "/etc/init.d" qui me lance le programme mpg123 sur un mp3. Et ça marche bien, je l'entend.
Je me loggue en user et dans un xterm je fais "mpg123 /mnt/MP3/ACDC_* &" Pas de pb, ça marche...
Au bout d'une heure ou deux, il a fini et je veux le relancer, par exemple avec : "mpg123 /mnt/MP3/ZZ_Top_83_Eliminator_* &" et là il me dit: "Can't open /dev/dsp"
Je me logge en root dans un xterm et je lance "/etc/init.d/Music" et il dit la même chose !
/dev/dsp, /dev/audio et /dev/mixer sont "crw-rw-rw- 1 root audio" et mon user est dans le group audio
Le "Sound Card Support" est compilé en dur dans le noyau ainsi que le support du circuit "SiS 7012" (noyau 2.4.19 recompilé à la maison avec sources de ftp.kernel.org)
un "# fuser -av /dev/audio" me montre que personne ne bloque le son (pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
Il y a certainement une application qui utilise le device, donc les ressouces sont occupées
Stéphane
On Sun, 07 Dec 2003 00:31:04 +0100, Hugolino wrote:
Salut,
Lors du démarrage, j'ai un exécutable "Music" dans "/etc/init.d" qui me
lance le programme mpg123 sur un mp3. Et ça marche bien, je l'entend.
Je me loggue en user et dans un xterm je fais "mpg123 /mnt/MP3/ACDC_* &"
Pas de pb, ça marche...
Au bout d'une heure ou deux, il a fini et je veux le relancer, par
exemple avec : "mpg123 /mnt/MP3/ZZ_Top_83_Eliminator_* &" et là il me
dit: "Can't open /dev/dsp"
Je me logge en root dans un xterm et je lance "/etc/init.d/Music" et il
dit la même chose !
/dev/dsp, /dev/audio et /dev/mixer sont "crw-rw-rw- 1 root audio" et mon
user est dans le group audio
Le "Sound Card Support" est compilé en dur dans le noyau ainsi que le
support du circuit "SiS 7012" (noyau 2.4.19 recompilé à la maison avec
sources de ftp.kernel.org)
un "# fuser -av /dev/audio" me montre que personne ne bloque le son
(pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
Il y a certainement une application qui utilise le device, donc les
ressouces sont occupées
On Sun, 07 Dec 2003 00:31:04 +0100, Hugolino wrote:
Salut,
Lors du démarrage, j'ai un exécutable "Music" dans "/etc/init.d" qui me lance le programme mpg123 sur un mp3. Et ça marche bien, je l'entend.
Je me loggue en user et dans un xterm je fais "mpg123 /mnt/MP3/ACDC_* &" Pas de pb, ça marche...
Au bout d'une heure ou deux, il a fini et je veux le relancer, par exemple avec : "mpg123 /mnt/MP3/ZZ_Top_83_Eliminator_* &" et là il me dit: "Can't open /dev/dsp"
Je me logge en root dans un xterm et je lance "/etc/init.d/Music" et il dit la même chose !
/dev/dsp, /dev/audio et /dev/mixer sont "crw-rw-rw- 1 root audio" et mon user est dans le group audio
Le "Sound Card Support" est compilé en dur dans le noyau ainsi que le support du circuit "SiS 7012" (noyau 2.4.19 recompilé à la maison avec sources de ftp.kernel.org)
un "# fuser -av /dev/audio" me montre que personne ne bloque le son (pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
Il y a certainement une application qui utilise le device, donc les ressouces sont occupées
Stéphane
hugolino
Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit:
On Sun, 07 Dec 2003 00:31:04 +0100, Hugolino wrote:
Salut, [snip]
un "# fuser -av /dev/audio" me montre que personne ne bloque le son (pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
Il y a certainement une application qui utilise le device, donc les ressouces sont occupées
Je suis bien d'accord avec toi, mais comment savoir quelle application l'utilise ?
Je croyais que "fuser" le permettait.
Merci
-- Hugo NPN -<°o)) "selon les théories neuropsycholinguistiques, nous opérons par matrices linéaires doublées d'une optimisation qui elle tourne en parallèle pour faire de la « prédiction d'embranchement »" -+- GA (in GLP ?) -+-
Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit:
On Sun, 07 Dec 2003 00:31:04 +0100, Hugolino wrote:
Salut,
[snip]
un "# fuser -av /dev/audio" me montre que personne ne bloque le son
(pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
Il y a certainement une application qui utilise le device, donc les
ressouces sont occupées
Je suis bien d'accord avec toi, mais comment savoir quelle application
l'utilise ?
Je croyais que "fuser" le permettait.
Merci
--
Hugo NPN -<°o))
"selon les théories neuropsycholinguistiques, nous opérons par matrices
linéaires doublées d'une optimisation qui elle tourne en parallèle pour
faire de la « prédiction d'embranchement »" -+- GA (in GLP ?) -+-
Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit:
On Sun, 07 Dec 2003 00:31:04 +0100, Hugolino wrote:
Salut, [snip]
un "# fuser -av /dev/audio" me montre que personne ne bloque le son (pareil avec /dev/dsp et /dev/mixer)
Qu'est ce qui a bien pu se passer ?
Il y a certainement une application qui utilise le device, donc les ressouces sont occupées
Je suis bien d'accord avec toi, mais comment savoir quelle application l'utilise ?
Je croyais que "fuser" le permettait.
Merci
-- Hugo NPN -<°o)) "selon les théories neuropsycholinguistiques, nous opérons par matrices linéaires doublées d'une optimisation qui elle tourne en parallèle pour faire de la « prédiction d'embranchement »" -+- GA (in GLP ?) -+-
Thomas Nemeth
Le dim 07 déc 2003 à 23:13, Hugolino a tapoté : | Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit: | > | > Il y a certainement une application qui utilise le device, donc les | > ressouces sont occupées | | Je suis bien d'accord avec toi, mais comment savoir quelle application | l'utilise ? | | Je croyais que "fuser" le permettait.
lsof aussi.
| Merci
'plaisir.
Thomas -- Ta mère elle se demande se qui se trame.
Le dim 07 déc 2003 à 23:13, Hugolino a tapoté :
| Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit:
| >
| > Il y a certainement une application qui utilise le device, donc les
| > ressouces sont occupées
|
| Je suis bien d'accord avec toi, mais comment savoir quelle application
| l'utilise ?
|
| Je croyais que "fuser" le permettait.
lsof aussi.
| Merci
'plaisir.
Thomas
--
Ta mère elle se demande se qui se trame.
Le dim 07 déc 2003 à 23:13, Hugolino a tapoté : | Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit: | > | > Il y a certainement une application qui utilise le device, donc les | > ressouces sont occupées | | Je suis bien d'accord avec toi, mais comment savoir quelle application | l'utilise ? | | Je croyais que "fuser" le permettait.
lsof aussi.
| Merci
'plaisir.
Thomas -- Ta mère elle se demande se qui se trame.
hugolino
Le 08 Dec 2003 19:44:45 GMT, Thomas Nemeth a écrit:
Le dim 07 déc 2003 à 23:13, Hugolino a tapoté : | Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit: | > | > Il y a certainement une application qui utilise le device, donc les | > ressouces sont occupées | | Je suis bien d'accord avec toi, mais comment savoir quelle application | l'utilise ? | | Je croyais que "fuser" le permettait.
lsof aussi.
'Tain, j'ai lu la page de man: "Manual page lsof(8) line 2511/2535 (END)", c'est long comme un jour sans pain et j'ai rien compris ;-)
Bon, je lance un "/usr/sbin/lsof | grep audio", et ça dit: cat 5031 hugo 1w CHR 14,4 354012 /dev/audio
un "kill -s 9 5031" plus tard, le son remarche ! Magique ! Donc lsof est plus fort que fuser (apparament seulement).
Car en fait, j'avais trouvé la solution :
Le son se bloquait quand je lançais une connection au Net, tout simplement car dans mon script /etc/ppp/ip-up, j'ai des lignes qui me joue un son (un après le flush de Postfix, un autre après le fetchmail, et un dernier après le fetchnews), ça me permet de savoir où le script en est et quand je peux me déconnecter. Or, ce script est exécuté en 'root' et moi je faisait mon fuser en 'hugo', donc je ne voyais rien. Et, j'ai testé, si un son joué en 'root' bloque le /dev/audio, un lsof en 'user' ne montre rien. Donc fuser et lsof: même caca.
Le problème est du au fait que certains sons ne rendent pas la main quand on les envoie sur /dev/audio par la commande 'cat'. 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 (ce que mon script faisait), 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 "&".
Il doit y avoir une petite merde dans certains sons qui fait que ça se passe mal...
Peut-être que ça pourrait entrer dans la FAQ de fcolc....
-- Hugo NPN -<°o)) Passe que moi, au départ, j'avais fait informatique comme études, pas NT, et je voudrais revenir à mon métier premier. -+- BB in Guide du Linuxien pervers - Bien configurer son métier.
Le 08 Dec 2003 19:44:45 GMT, Thomas Nemeth a écrit:
Le dim 07 déc 2003 à 23:13, Hugolino a tapoté :
| Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit:
| >
| > Il y a certainement une application qui utilise le device, donc les
| > ressouces sont occupées
|
| Je suis bien d'accord avec toi, mais comment savoir quelle application
| l'utilise ?
|
| Je croyais que "fuser" le permettait.
lsof aussi.
'Tain, j'ai lu la page de man: "Manual page lsof(8) line 2511/2535 (END)",
c'est long comme un jour sans pain et j'ai rien compris ;-)
Bon, je lance un "/usr/sbin/lsof | grep audio", et ça dit:
cat 5031 hugo 1w CHR 14,4 354012 /dev/audio
un "kill -s 9 5031" plus tard, le son remarche ! Magique !
Donc lsof est plus fort que fuser (apparament seulement).
Car en fait, j'avais trouvé la solution :
Le son se bloquait quand je lançais une connection au Net, tout
simplement car dans mon script /etc/ppp/ip-up, j'ai des lignes qui me
joue un son (un après le flush de Postfix, un autre après le fetchmail,
et un dernier après le fetchnews), ça me permet de savoir où le script
en est et quand je peux me déconnecter.
Or, ce script est exécuté en 'root' et moi je faisait mon fuser en
'hugo', donc je ne voyais rien.
Et, j'ai testé, si un son joué en 'root' bloque le /dev/audio, un lsof
en 'user' ne montre rien.
Donc fuser et lsof: même caca.
Le problème est du au fait que certains sons ne rendent pas la main
quand on les envoie sur /dev/audio par la commande 'cat'.
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 (ce que mon script faisait), 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 "&".
Il doit y avoir une petite merde dans certains sons qui fait que ça se
passe mal...
Peut-être que ça pourrait entrer dans la FAQ de fcolc....
--
Hugo NPN -<°o))
Passe que moi, au départ, j'avais fait informatique comme études, pas NT,
et je voudrais revenir à mon métier premier.
-+- BB in Guide du Linuxien pervers - Bien configurer son métier.
Le 08 Dec 2003 19:44:45 GMT, Thomas Nemeth a écrit:
Le dim 07 déc 2003 à 23:13, Hugolino a tapoté : | Le Sun, 07 Dec 2003 21:21:03 +0100, tatane a écrit: | > | > Il y a certainement une application qui utilise le device, donc les | > ressouces sont occupées | | Je suis bien d'accord avec toi, mais comment savoir quelle application | l'utilise ? | | Je croyais que "fuser" le permettait.
lsof aussi.
'Tain, j'ai lu la page de man: "Manual page lsof(8) line 2511/2535 (END)", c'est long comme un jour sans pain et j'ai rien compris ;-)
Bon, je lance un "/usr/sbin/lsof | grep audio", et ça dit: cat 5031 hugo 1w CHR 14,4 354012 /dev/audio
un "kill -s 9 5031" plus tard, le son remarche ! Magique ! Donc lsof est plus fort que fuser (apparament seulement).
Car en fait, j'avais trouvé la solution :
Le son se bloquait quand je lançais une connection au Net, tout simplement car dans mon script /etc/ppp/ip-up, j'ai des lignes qui me joue un son (un après le flush de Postfix, un autre après le fetchmail, et un dernier après le fetchnews), ça me permet de savoir où le script en est et quand je peux me déconnecter. Or, ce script est exécuté en 'root' et moi je faisait mon fuser en 'hugo', donc je ne voyais rien. Et, j'ai testé, si un son joué en 'root' bloque le /dev/audio, un lsof en 'user' ne montre rien. Donc fuser et lsof: même caca.
Le problème est du au fait que certains sons ne rendent pas la main quand on les envoie sur /dev/audio par la commande 'cat'. 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 (ce que mon script faisait), 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 "&".
Il doit y avoir une petite merde dans certains sons qui fait que ça se passe mal...
Peut-être que ça pourrait entrer dans la FAQ de fcolc....
-- Hugo NPN -<°o)) Passe que moi, au départ, j'avais fait informatique comme études, pas NT, et je voudrais revenir à mon métier premier. -+- BB in Guide du Linuxien pervers - Bien configurer son métier.
