[PATCH 1/7] move module_audio_init from each module to the module_util.c

[Bohdan R . Rau]

On Mon, 29 Nov 2010 17:31:52 -0500, Trevor Saunders
<trev.saunders at gmail.com> wrote:
> On Mon, Nov 29, 2010 at 10:09:05PM +0100, Bohdan R. Rau wrote:
[...]
>> I still can't understand - why it's not possible to return audio data
>> from
>> external command to generic module and play the wave using internal
>> speechd
>> audio output...
>> 
>> Something like (simplified):
>> 
>> GenericAudioOutput "pipe"
>> GenericExecuteSynth "my_super_synthesis_software [some params] -o -"
> 
> I can think of a couple reasons.
> 
> 1. the current way is more generic,

No, it's not

> what about synths that can't send
> data back through a pipe etc.

That's why I propose GenericAudioOutput configuration parameter (and some
other). We still can use hardware synthesizer or software synthesizers
using it's own audio output, and we can not rely on $PLAY_COMMAND inside
GenericExecuteString (see note at end).

> 2. its easier currently you just set the play command in a piece of
> shell code that's executed with  system(), if we where to do what you
> propose we'd need a lot more code.

At first: I don't think this part of code is most ugly in all
speech-dispatcher sources only because I found some more ugly.
At second: not a lot more code, but several lines.

Something like:

if (!strcmp(GenericAudioOutput,"pipe")) pipe(from_generic);
if (!strcmp(GenericAudioInput,"pipe")) pipe(to_generic);
pid=fork();
if (pid<0) {
   /* close pipes and return */
  return;
}
if (!pid) {
  setenv("DATA",something_to_say);
  setenv("SOME_PARAMETER",some_parameter);
  /* more initialization code here */
  execl("/bin/sh","sh","-c",GenericExecuteString,NULL);
}
else {
/* close unwanted ends of pipes */
if (!strcmp(GenericAudioInput,"pipe")) /*write something_to_say to
"to_generic" pipe and close this end */
if (!strcmp(GenericAudioOutput,"pipe")) /* read wave from "from_generic"
pipe and send to audio subsystem, using GenericOutputFormat */
waitpid(pid,NULL,0);


In fact, we can use more generic commands - for example if we provide
GenericCommandInterpreter and GenericCommandOption parameters, we can write
short programs in any interpreted language (perl, python) directly as
GenericExecuteString, for example:

GenericCommandInterpreter "/usr/bin/python"
GenericCommandParameter "-c"
GenericExecuteSynth "some lines in python"

... and at third: do you want to say you are as lazy as me? :)

ethanak
PS. Note: yes, the part of code obtaining PLAY_COMMAND is most ugly
fragment of speech-dispatcher code :)
-- 
http://milena.polip.com/ - Pa pa, Ivonko!