On Thu, 12 Oct 2006, Sébastien Hinderer wrote:
Hi again,
Yes that's one of the first issues I spotted when I tried to make my own
voice file. I think the maximum has indeed been reached. Now it seems it
only fits by making the speech faster (so it takes less time) :-). We
can't just stop adding more speech though: features keep being added, and
newer players have more resources. We need to work out a solution for
this. One way would be to have the Archos load only the most essential
clips and do without the rest. Alternatively, we could break the
monolithic voice file concept somehow, loading clips on demand and keeping
a cache... But perhaps this has been discussed before?
Another approach would be to embed a text-to-speech engine into RB.
Is this totally irrealistic ?
I imagine some of the newer players could do it, but I'm not so sure about
older models like the Archos, which is the one that is running out of RAM
for the voice clips IIUC. There are not many free TTS engines out there,
and none that I know of that would be directly usable. You could start
with flite or espeak, or perhaps license something commercial or MBROLA.
You'd probably have to change all the math in there to fixed point, and
possibly optimize things, for it to run fast enough. Obviously that's
pretty difficult. And make sure to provide whatever services they need
from the OS. Even so I believe flite and MBROLA require a few megabytes of
reference data, AFAIK only espeak might be tiny enough to be smaller than
the voice clips.
Keep in mind too that a TTS would be a lot more slugghish than prerecorded
messages, so it would probably be less responsive than with voice clips.
The gain would be the ability to speak arbitrary text, not to have to
worry about missing voice file entries. One could then proceed to code a
text/html reader application. But perhaps at this point it would be best
to move to a PDA with a general purpose OS, because you're likely to want
all sorts of other services.
So in short, no I don't think a TTS for RB would be realistic.
--
Stéphane Doyon
<[EMAIL PROTECTED]>
http://pages.infinit.net/sdoyon/
