null

Posté par eastwind☯ le 17 août 2012 à 20:56.

Étiquettes : aucune

août

2012

Slt,

J'utilise le moteur de synthèse vocale ekho, et j'aurais besoin dans mon script de rediriger la sortie audio vers ／dev/null .

Ensuite comment rediriger la sortie audio vers sa sortie normal (la carte son ).

# /dev/null

Posté par Marotte ⛧ le 17 août 2012 à 23:10. Évalué à 2.

Si tu envois la sortie sur /dev/null elle est perdue.

Je comprends pas ce que tu veux dire par :

Ensuite comment rediriger la sortie audio vers sa sortie normal (la carte son ).

Si j'ai compris de travers ta demande alors deux questions :

Vers quoi la sortie audio de ekho est redirigé par défaut ?

Qu'essayes-tu de faire ? Plus précisément.
- [^] # Re: /dev/null
  
  Posté par eastwind☯ le 17 août 2012 à 23:51. Évalué à 3. Dernière modification le 17 août 2012 à 23:52.
  
  normalement ekho va diriger son flux audio sur ma carte son, j'aimerais qu'elle soit dirigé vers /dev/null pour certains traitement, notamment lorsque j'utilise ekho en tant que "générateur de fichier csv" pour calculer le temps d'execution d'une prononciation (via la commande time , dont la syntaxe en passant ne semble pas très POSIX compliant).
  
  Après ce traitement , bien entendu je veux remettre le flux audio vers la sortie de ma carte son plutot que /dev/null
  - [^] # Re: /dev/null
    
    Posté par Marotte ⛧ le 17 août 2012 à 23:54. Évalué à 2.
    
    OK c'est plus clair. Mais je connais pas ekho donc je peux pas plus t'aider. Mais merci quand même d'avoir précisé.
    - [^] # Re: /dev/null
      
      Posté par eastwind☯ le 17 août 2012 à 23:56. Évalué à 2.
      
      c'est pas un problème par rapport à ekho c'est un problème par rapport au (semble t-il ) non respect du principe Unix du tout fichier.
      
      Disons qu'avant pulse audio , je pouvait me débrouiller étant donnée que /dev/OSS ou alsa semblait avoir respecté ce principe. Maintenant je n'y arrive plus.
      - [^] # Re: /dev/null
        
        Posté par Marotte ⛧ le 18 août 2012 à 00:03. Évalué à 2.
        
        Ah bah ça, pusleaudio pour faire des trucs qui sortent un peu des sentiers battus c'est pas folichon j'ai l'impression.
        
        Est-ce que ekho supporte jack ? Parce que là c'est facile, quand tu fais tes tests avec time tu déconnectes la sortie de ekho (hop pas de son), puis tu as juste à reconnecter quand tu le désires pour avoir du son…
        
        [^] # Re: /dev/null
        
        Posté par eastwind☯ le 18 août 2012 à 10:49. Évalué à 2.
        
        comment le savoir ?
        
        [^] # Re: /dev/null
        
        Posté par Marotte ⛧ le 18 août 2012 à 10:59. Évalué à 2. Dernière modification le 18 août 2012 à 11:03.
        
        J'allais essayer de regarder pour toi sur le site officiel d'ekho mais je le trouve pas… Pour le savoir il faudrait voir sur ce site je pense.
        
        À moins que ça est un rapport avec http://www.cross-plus-a.com/balabolka.htm ?
        
        [^] # Re: /dev/null
        
        Posté par eastwind☯ le 18 août 2012 à 11:03. Évalué à 2.
        
        le site officiel http://www.eguidedog.net/ekho.php ne le mentionne pas, existe t-il une commande pour le vérifier ?
        
        [^] # Re: /dev/null
        
        Posté par Marotte ⛧ le 18 août 2012 à 11:23. Évalué à 2.
        
        Il y a pas de commande pour ça à ma connaissance.
        
        D'après :
        
        +----------------+ | Web TTS Client | +----------------+-------+------------------+---------------+---------+ | Web TTS Server | SAPI5 | OpenTTS/ | Command Line/ | Android | | | | SpeechDispatcher | Gtk+ | | +----------------+-------+------------------+---------------+---------+ | Ekho Library | +----------+------------+------------+---------+--------+-------------+ | Dict | Festival | SoundTouch | Sndfile | Lame | Pulseaudio | +----------+------------+ / +---------+ / +-------------+ | utfcpp | sr-convert | Sonic | GSM | Vorbis | +----------+------------+------------+---------+--------+
        
        On dirait pas. Et si dans les options tu n'as pas le choix d'utiliser différents backends audio (ALSA, OSS, Pulseaudio, Jack) je dirais que c'est retour à la case départ pour ton problème :( À moins qu'il y ait un outil qui permette de transformer une appli qui n'utiliserait que Pulseaudio en client Jack mais là je ne sais pas.
        
        [^] # Re: /dev/null
        
        Posté par Marotte ⛧ le 18 août 2012 à 11:29. Évalué à 2.
        
        Il y a peut-être des pistes à creuser : http://docs.fedoraproject.org/en-US/Fedora/14/html/Musicians_Guide/sect-Musicians_Guide-Integrating_PulseAudio_with_JACK.html
        
        Mais là je peux pas t'aider, je fais pas ce genre de truc et j'ai pas trop le temps de chercher pour toi :/
        
        [^] # Re: /dev/null
        
        Posté par eastwind☯ le 18 août 2012 à 11:54. Évalué à 2. Dernière modification le 18 août 2012 à 11:59.
        
        Je te remerci pour tout , mais je pense que je vais finalement simplement faire afficher un message d'avertissement , afin de savoir qu'il faut éteindre ses hauts-parleurs pendant le traitement.
        
        Dans le cas présent , ce que je trouve particulièrement dommage c'est qu'une chose que je pouvais faire simplement et rapidement (grace aux principes unix de redirection et de fichier ) , je ne peux plus le faire simplement. Ici, la complexité pour régler un problème trivial augmente de manière géométrique par rapport à son seuil inital (qui était celui qui est le plus proche de l'idéal en terme d'investissement de temps par rapport au résultat escompté).
        
        de manière quantifié il est simple de voir qu'une ligne de commande m'aurais pris tout au plus 10 minutes (pour faire large ). Dans le cas présent , si l'on prend pour point de départ le message inital est posté à 20:56 , il est maintenant 11:39 , si l'on ne compte pas les temps non passé à essayer de trouver une solution (sommeil , repas … ), alors on a environs
        
        20:46 à 23:10 = 2h24 minutes 23:10 à 00:03 = 47 minutes 10:59 à 11:29 = 30 minutes
        
        Total = 3 h41 minutes (sans compter ce post ci) soit 221 minutes.
        
        En comparant avec le temps inital idéal ( 10 minutes ) , nous avons une augmentation de ((221 minutes * 100 ) /10） 2210 % avec un résultat tout aussi négatif, dont la dernière piste emmène au delà du but original et promet une augmentation de la complexité encore plus géométrique, sans aucune garantie de résultat.
        
        Je pense que c'est ce qu'on appel le cout de la complexité qui entraine un gaspillage énorme de temps pour un résultat ridicule ou meme sans retour du tout.
        
        Cela nous apprends aussi que la simplicité proné par les principes Unix ont pour effet de contenir cette augmentation géométrique de la complexité pour un résultat supérieur. Ainsi suivre ceux-ci permet de garder le seuil d'investissement à son niveau le plus optimal dans une situation donnée.
        
        L'on comprend dès lors la frustration de l'usager lorsqu'un composant important de l'ordinateur (le serveur de son ) , envoie ballader ces principes (qui ont fait leur preuve). Et lorsque ce type de comportement s'étend à d'autres partie du système (par exemple la journalisation ) tout aussi stratégique, la fustration ne peut que faire qu'augmenter. Ce n'est ici pas une querelle de chapelle , mais une question d'efficacité.
        
        (et j'ai encore sous estimé le temps car j'ai pris pour point de départ le premier message , alors qu'en fait cela vient bien avant)
        
        [^] # Re: /dev/null
        
        Posté par Marotte ⛧ le 18 août 2012 à 12:06. Évalué à 2.
        
        D'un autre côté le programme que tu utilises à part l'air à fond dans le principe Unix…
        
        Mais j'y pense. Tu dois bien avoir une ligne de commande pour mettre le son de pulseaudio à zero ou le remettre à max ? Tu fais un script wrapper (je trouve pas le terme français) qui va mettre le volume à 0 puis lancer ton programme, puis un autre script qui remet le volume au niveau désiré et lance le programme ?
        
        [^] # Re: /dev/null
        
        Posté par eastwind☯ le 18 août 2012 à 12:15. Évalué à 2. Dernière modification le 18 août 2012 à 12:16.
        
        ekho est dans la philosphie Unix il serait abhérant que ce soit à un logiciel de synthèse vocale de s'occuper des questions de direction de son du système d'exploitation. Cela irait à l'encontre meme des principes:)
        
        Je te laisse imaginer l'augmentation drastique de la complexité et de son cout.
        
        [^] # Re: /dev/null
        
        Posté par claudex le 18 août 2012 à 12:09. Évalué à 3.
        
        Vu que tu utilise pulseaudio, je ne comprend pas pourquoi tu n'utilise pas simplement la fonctionnalité de modifier le volume d'une application via l'outil en ligne de commande de pulseaudio http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/CLI . Un truc comme pactl set-sink-input-mute [sink Index no.] 1 devrait marcher.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: /dev/null
        
        Posté par eastwind☯ le 18 août 2012 à 12:17. Évalué à 2. Dernière modification le 18 août 2012 à 12:18.
        
        Je ne connais pas cet commande, mais n'a elle pas pour effet d'enlever la portabilité ? (tout le monde n'a pas pulseaudio, par exemple certains utilise jack ou autre s'il en existe ).
        
        j'aimerais garder le script avec le minimum de dépendance spécifique et un maximum de portabilité.
        
        [^] # Re: /dev/null
        
        Posté par claudex le 18 août 2012 à 12:49. Évalué à 3.
        
        mais n'a elle pas pour effet d'enlever la portabilité ?
        
        Sans doute mais tu peux tenter de détecter si la commande existe et si oui l'utiliser, sinon tu fais autre chose.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: /dev/null
        
        Posté par eastwind☯ le 18 août 2012 à 11:13. Évalué à 2.
        
        à priori, rien en commun avec balabolka
        
        [^] # Re: /dev/null
        
        Posté par Marotte ⛧ le 18 août 2012 à 11:26. Évalué à 2. Dernière modification le 18 août 2012 à 11:26.
        
        Il y a l'utilisation de SAPI (standard speech API on Windows platform) quand même en commun. Oui je sais ça aide pas.
  - [^] # Re: /dev/null
    
    Posté par tiot (site web personnel) le 20 août 2012 à 12:05. Évalué à 3.
    
    Tu ne peux pas faire un truc comme :
    ekho -t wav -o /dev/null
    - [^] # Re: /dev/null
      
      Posté par eastwind☯ le 20 août 2012 à 18:16. Évalué à 2.
      
      ha oui simplemennt (j'étais tellment dans les redirection que j'y ai pas pensé)
# Utilise la sortie fichier !

Posté par ze_lionix (site web personnel) le 20 août 2012 à 12:16. Évalué à 2.

D'après ce que j'ai compris tu veux surtout connaître le temps de prononciation d'un texte.

Quand je regarde la syntaxe de la commande ekho :
(…)
-o, --output=FILE Output to file.

Utiliser la sortie fichier revient à ce que tu essaye de faire avec la redirection /dev/null

=> soit tu fais un time sur le temps de génération du fichier ( pas top car I/O, charge machine..etc)

=> soit tu génère le fichier et tu utilises sox ( option stat ) pour avoir la longueur.

Je viens de tester et pour dire 'Linux est puissant' en mandarin il faut 2.09s.

Fuse : j'en Use et Abuse !
# finalement

Posté par eastwind☯ le 20 août 2012 à 18:19. Évalué à 2.
j'ai écris un code qui en meme temps qu'il prononce , mesure le temps dans un fichier :
```
{ time  ekho $( cut -d '.' -f2 $OneWordisplay | awk NR==1 ) >stdout 2>stderr; } 2>$timeTwo;
```
j'ajouterais surement le code
```
ekho -t wav -o /dev/null 
```
lorsque j'aurais le temps pour en faire une fonction spécifique.

Merci

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.