Je veux enregistrer une émission radio qui vient de ma chaîne hifi.
J'arrive à encoder en wav avec l'outil rec de la distribution sox:
$ rec -r 44100 -c 2 -t wav coucou.wav
J'ai eu beaucoup de mal à faire marcher cela; pour ceux qui
chercheraient des infos sur google, j'expose mon problème et la
solution. Dès que je lançais rec, j'obtenais:
/dev/dsp: device or resource busy
Pourtant, aucun logiciel n'utilisait /dev/dsp: $ fuser -v /dev/dsp ne
donnait rien. De plus, j'avais pris la précaution de tuer artsd, ou bien
de faire $ artshell suspend. Rien n'y faisait.
Finalement, j'ai trouvé la solution en déchargeant puis chargeant les
modules de son:
Voilà. Ne me demandez pas pourquoi ça marche.
Maintenant que je sais enregistrer un son en wav, je veux encoder à la
volée, en mp3 ou en ogg.
Voici une commande qui marche:
On obtient une erreur:
ERROR: Input file "(stdin)" is not a supported format
C'est pourtant censé être la même chose.
2// Deuxième question: toujours avec oggenc, pourquoi une durée restante
apparaît:
[ 0,1%] [203m28s remaining]
À aucun moment je ne vois mention d'une telle chose, ni moyen de
modifier le temps d'encodage (man oggenc).
3// Lorsqu'on change la source d'enregistrement avec Aumix (par
exemple), que fait-il exactement sur le système? Où peut-on voir les
changements? Je ne vois rien changer dans /dev/sound/mixer et
/dev/sound/dsp.
4// Si un processus gourmand en cpu tourne par ailleurs, il se peut
qu'il y ait des sauts dans le mp3 (ou ogg) correspondant. Est-ce que
quelqu'un a de l'expérience sur la manière d'utiliser la commande nice
pour éviter ce genre de désagréments?
J'ai vu qu'il existait d'autres outils que rec pour enregistrer du son.
J'essaie néanmoins de me cantonner aux utilitaires de sox.
Merci d'avance à la communauté pour une réponse à une ou plusieurs de
ces questions.
Julien
--
------------------------------------
Powered by GNU/Linux
------------------------------------
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
no_spam
On Tue, 27 Apr 2004 15:35:10 +0200, Julien SCORDIA wrote:
Salut à tous,
J'ai eu beaucoup de mal à faire marcher cela; pour ceux qui chercheraient des infos sur google, j'expose mon problème et la solution. Dès que je lançais rec, j'obtenais:
/dev/dsp: device or resource busy
Pourtant, aucun logiciel n'utilisait /dev/dsp: $ fuser -v /dev/dsp ne donnait rien. De plus, j'avais pris la précaution de tuer artsd, ou bien de faire $ artshell suspend. Rien n'y faisait. Finalement, j'ai trouvé la solution en déchargeant puis chargeant les modules de son:
Ca veut dire que le module est buggé et gère mal le compte d'ouverture de /dev/dsp.
On obtient une erreur: ERROR: Input file "(stdin)" is not a supported format
Apparement, quand tu rediriges explicitement sur stdout, il prend stdin comme entrée et non plus /dev/dsp. Il a donc plus de mal à connaitre les propriétés du flux audio...
3// Lorsqu'on change la source d'enregistrement avec Aumix (par exemple), que fait-il exactement sur le système? Où peut-on voir les changements? Je ne vois rien changer dans /dev/sound/mixer et /dev/sound/dsp.
Si tu avais un oeil dans le hard, tu verrais le changement. Effectivement, rien n'est visible au niveau user, il n'y a que le driver qui éventuellement garde l'info en mémoire pour éviter d'accéder au hard si on la lui demande.
4// Si un processus gourmand en cpu tourne par ailleurs, il se peut qu'il y ait des sauts dans le mp3 (ou ogg) correspondant. Est-ce que quelqu'un a de l'expérience sur la manière d'utiliser la commande nice pour éviter ce genre de désagréments?
Utiliser un kernel "low-latency" et préemptif. C'est à dire soit un 2.4 patché, soit un 2.6.
On Tue, 27 Apr 2004 15:35:10 +0200, Julien SCORDIA wrote:
Salut à tous,
J'ai eu beaucoup de mal à faire marcher cela; pour ceux qui
chercheraient des infos sur google, j'expose mon problème et la
solution. Dès que je lançais rec, j'obtenais:
/dev/dsp: device or resource busy
Pourtant, aucun logiciel n'utilisait /dev/dsp: $ fuser -v /dev/dsp ne
donnait rien. De plus, j'avais pris la précaution de tuer artsd, ou bien
de faire $ artshell suspend. Rien n'y faisait.
Finalement, j'ai trouvé la solution en déchargeant puis chargeant les
modules de son:
Ca veut dire que le module est buggé et gère mal le compte d'ouverture
de /dev/dsp.
On obtient une erreur:
ERROR: Input file "(stdin)" is not a supported format
Apparement, quand tu rediriges explicitement sur stdout, il prend
stdin comme entrée et non plus /dev/dsp. Il a donc plus de mal
à connaitre les propriétés du flux audio...
3// Lorsqu'on change la source d'enregistrement avec Aumix (par
exemple), que fait-il exactement sur le système? Où peut-on voir les
changements? Je ne vois rien changer dans /dev/sound/mixer et
/dev/sound/dsp.
Si tu avais un oeil dans le hard, tu verrais le changement.
Effectivement, rien n'est visible au niveau user, il n'y a que le
driver qui éventuellement garde l'info en mémoire pour éviter d'accéder
au hard si on la lui demande.
4// Si un processus gourmand en cpu tourne par ailleurs, il se peut
qu'il y ait des sauts dans le mp3 (ou ogg) correspondant. Est-ce que
quelqu'un a de l'expérience sur la manière d'utiliser la commande nice
pour éviter ce genre de désagréments?
Utiliser un kernel "low-latency" et préemptif.
C'est à dire soit un 2.4 patché, soit un 2.6.
On Tue, 27 Apr 2004 15:35:10 +0200, Julien SCORDIA wrote:
Salut à tous,
J'ai eu beaucoup de mal à faire marcher cela; pour ceux qui chercheraient des infos sur google, j'expose mon problème et la solution. Dès que je lançais rec, j'obtenais:
/dev/dsp: device or resource busy
Pourtant, aucun logiciel n'utilisait /dev/dsp: $ fuser -v /dev/dsp ne donnait rien. De plus, j'avais pris la précaution de tuer artsd, ou bien de faire $ artshell suspend. Rien n'y faisait. Finalement, j'ai trouvé la solution en déchargeant puis chargeant les modules de son:
Ca veut dire que le module est buggé et gère mal le compte d'ouverture de /dev/dsp.
On obtient une erreur: ERROR: Input file "(stdin)" is not a supported format
Apparement, quand tu rediriges explicitement sur stdout, il prend stdin comme entrée et non plus /dev/dsp. Il a donc plus de mal à connaitre les propriétés du flux audio...
3// Lorsqu'on change la source d'enregistrement avec Aumix (par exemple), que fait-il exactement sur le système? Où peut-on voir les changements? Je ne vois rien changer dans /dev/sound/mixer et /dev/sound/dsp.
Si tu avais un oeil dans le hard, tu verrais le changement. Effectivement, rien n'est visible au niveau user, il n'y a que le driver qui éventuellement garde l'info en mémoire pour éviter d'accéder au hard si on la lui demande.
4// Si un processus gourmand en cpu tourne par ailleurs, il se peut qu'il y ait des sauts dans le mp3 (ou ogg) correspondant. Est-ce que quelqu'un a de l'expérience sur la manière d'utiliser la commande nice pour éviter ce genre de désagréments?
Utiliser un kernel "low-latency" et préemptif. C'est à dire soit un 2.4 patché, soit un 2.6.
