Re: [CBLX] Pico2wave avec speech-dispatcher

[coolbrother@xxxxxxxxxx]

Je continue à m'exciter tout seul,
car hier j'étais pressé d'aller me coucher et donc je n'avais plus la
force d'écrire tout ce que je souhaitais dire sur les théoritiens de
l'informatique :
Je n'ai rien contre les philosophes linuxiens, il faut de tout pour faire un
monde, et après tout, ça peut être amusant de les écouter.
On en a un ici qui fait bien son job, fidèle au poste, et pour ne pas le
nommer, Pierre, avec
tous ses défauts, on l'aime bien quand même parce que déjà
c'est un modèle des années 50, qui ne se fait plus, mais qui tombe
rarement en
panne quand on en a besoin.
Bien sûr qu'il a 20 trains de retard en informatique, il programme encore en
lisp, et ces références sont RMS et d'autres otistes du début de l'ère
informatique,
qui sont eux aussi en voie de disparition.
mais bon on le connaît, et il nous rappelle que programmer
n'était pas très drôle avant.
Et en plus, on sait comment le gérer, il suffit de lui laisser le dernier
mot,
et tout va bien.

Mais ce qui me dérange, c'est que d'autres se mettent à l'immiter.
Et alors là quand il y en a plusieurs, ça devient ingérable.

Donc concrètement :

Gérémy :
>>> Je confirme que fonctionne:
>>> # cat test.wav | aplay
>>>
>>> Mais pas :
>>> # cat test.wav | mplayer
>>>
>>
>
> si si cela fonctione ... il faut juste rajouter un -
>
> ce qui donne :
>
> # cat test.wav | mplayer -
>
>
i
Chez moi  ça ne marche pas car ça donne :
# cat test.wav | mplayer -

MPlayer 1.0rc3-4.4.4 (C) 2000-2009 MPlayer Team

Playing -.
Reading from stdin...
Cannot seek backward in linear streams!


Exiting... (End of file)

Dominique:
>> Quoiqu'il en soit, aplay est NETTEMENT plus léger et BIEN mieux adapté
>> pour ce qu'on veut faire alors inutile de se prendre la tête avec
>> l'usine à gaz de mplayer, certes puissant mais pour ce à quoi il est
>> fait.
>>
>>
> certes
>
>> D'autre part, le mécanisme de pipe est la plupart du temps plus
>> efficace que des fichiers intermédiaires puisque dans ce le cas du
>> pipe, le process consommateur, en l'occurrence aplay, n'a pas besoin
>> d'attendre que le producteur (pico2wave) ait fini de créer le wave
>> pour démarrer et traiter ce qu'il a déjà reçu, d'où un gain de
>> réactivité bien utile dans ce genre d'appli.
>>
>> dom
>> --
>
Je replace le contexte ici, il s'agit d'un fichier de configuration de
speech-dispatcher qui fait appel à des applis hétérogènes,
donc on ne peut pas se prononcer sur pipe ou pas, déjà qu'en script bash,
on ne
peut pas faire ce que l'on veut avec les tubes, notamment les accumuler.
Et dans le cas présent, avec aplay :
# pico2wave -w /tmp/test.wav "bonjour tout le monde." | aplay
ne fonctionne pas.
Et encore moins dans la commande du script qui serait avec un tube:
GenericExecuteSynth \
"pico2wave -w $TMPDIR/pico.wav -l $VOICE \'$DATA\' | $PLAY_COMMAND
Donc ni Dominique ni Raphaël ont raison dans ce cas-là.
Mais je reste toujours preneur d'une solution.

Pour finir, je retire tout ce que j'ai dis sur Pierre,
et je m'excuse par avance de tout ce que je dirai sur lui dans un futur
proche.

A bientôt:
Sam

>
>
> Le 21/09/2011 01:08, Dominique Asselineau a écrit :
>>
>> --
>>
>>> Justement, il faut vérifier, car ça marche pas avec mplayer.
>>> Et surtout il faut en finir avec cette supposition,
>>> parce qu'il y a toujours quelqu'un pour dire que ce serait mieux avec
>>> un
>>> tube,
>>> sans prendre la peine de se renseigner.
>>> Alors si ça marche avec mplayer, postez la solution, et on en parle
>>> plus.
>>> Je confirme que fonctionne:
>>> # cat test.wav | aplay
>>>
>>> Mais pas :
>>> # cat test.wav | mplayer
>>>
>>
>
> si si cela fonctione ... il faut juste rajouter un -
>
> ce qui donne :
>
> # cat test.wav | mplayer -
>
>
>
>> Il faut probablement des options pour que ça marche.
>>
>>
>
> oui juste un espace et un tiret
>> Quoiqu'il en soit, aplay est NETTEMENT plus léger et BIEN mieux adapté
>> pour ce qu'on veut faire alors inutile de se prendre la tête avec
>> l'usine à gaz de mplayer, certes puissant mais pour ce à quoi il est
>> fait.
>>
>>
> certes
>
> Jérémy
>> D'autre part, le mécanisme de pipe est la plupart du temps plus
>> efficace que des fichiers intermédiaires puisque dans ce le cas du
>> pipe, le process consommateur, en l'occurrence aplay, n'a pas besoin
>> d'attendre que le producteur (pico2wave) ait fini de créer le wave
>> pour démarrer et traiter ce qu'il a déjà reçu, d'où un gain de
>> réactivité bien utile dans ce genre d'appli.
>>
>> dom
>> --
>>
>> ---
>>
>
> ---
> --
>    CarrefourBLinuX MailingListe
>    Pour obtenir de l'aide, envoyez le sujet  help  à:
>    carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
>    Archives:
>    http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux
>
>



---
--
   CarrefourBLinuX MailingListe
   Pour obtenir de l'aide, envoyez le sujet  help  à:
   carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
   Archives:
   http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux