[tuxdroid-user] Dedicated sound normalizer / multiplexer daemon

[Florent T. <ft...@gm...>]

Hi

If we want "ultimate" modularity for soud (be it the choice of TTS
engine, STT, or any sound-enabled sound), we may want to develop/find
a dedicated sound daemon that:

- creates a virtual sound device with an explicit naming convention (
/dev/tuxmic & /dev/tuxspk for example)
- downsamples/transcodes every incoming sound to 8bit 8khz sound (for
instance, try to play an mp3 with xmms, it won't work :p)
- eventually filters the 500 Hz noise coming from the mic
- acts as a frontend for the TTS engines (if you input text to the
daemon, it uses TTS; if it's sound, it sends it to tux)
- handles multiplex / queuing of sound events (the wav merger doesn't
seem to me a long-term solution...)
- sound normalization to handle the mouth problem (open/close)
- avoid/postpone tux animation when microphone usage is needed

There's an inherent problem with the mic: it's in the mouth (it's one
of the most discutable technical choices to me...), but WHY? Speech
recognition programs rely heavily on a good sound level tuning, and
the fact that the sound level varies from 50% when opening the mouth
will not help...

Another technical choice that makes me wonder: there's a line in / out
in the back of tux... But if i'm not mistaken, it will be limited to 8
bits / 8khz. So these I/O won't really add feature, except for
earphone operation...

Well, sorry to look mean, i'm just wondering why the engineering team
did these choices...

What do you think?