So I thought I'd see why everyone talked about flite, but didn't use it. The download page for flite even has a linux ARM binary!

The first thing I noticed was that it wanted a newer version of libc. My empeg has 2.1.2 (I'm running 2.0b11) and flite wants 2.1.3. So I grabbed the libc6 package from debian Potato (also pre-compiled for ARM). I did kinda get myself in trouble here... I wasn't thinking about it when I went to swap in the new libc. I rm'd the link to the old one and tried to put a link pointing to the new one. Well, the ln command doesn't work when neither of them is there (duh). Luckily, I was able to use kftpd to put the new one in place (since it's in the kernel and not trying to load libc every time I type something).

Anyway, with flite and libc 2.1.3, I gave it a try. Well, it can't output audio directly on the empeg, but it can create a .wav file. So I created a simple text file and had flite read the text into a .wav. Then I used pcmplay to play the wav. Since flite created a 8KHz mono sample and pcmplay assumes 44KHz stereo, it just sounds like a high-pitched beep.

Rather than do a proper re-sampling, I wrote a quick hack to just read 2 bytes (16 bit samples) and write those same 2 bytes back 11 times. The result actually sounds decent.

The next challenge was to make it so you don't have to run 3 commands everytime you want it to say something. To do this, I created a fifo and added to my sample duplicator prog to sit in a loop reading from the fifo. I have a wrapper shell script around this that pipes the output to pcmplay too. Then I called the shell script from preinit.

The end result? I can read any text file on the system with a single command.

It still needs a bit of work smothing things out though. Installation is a bit tedious and I don't have a readme, but I'll see if I can put some sort of package together with some basic instructions tonight.

I'm a little nervous that the libc2.1.3 (from debian) is only 900K whereas the 2.1.2 (empeg 2.0b11) is 950K. Maybe my player won't boot next time I shutdown.... I'll make sure to test this before giving out instructions

ROCK!

I had gotten as far as the "three separate commands" solution. (flite -> rateconv -> pcmplay.) I hadn't thought of a fifo -> pcmplay solution. I was thinking that it'd be nice if Flite could be patched to write directly to the empeg's sound device after the sound is up-sampled, but that's probably a bigger step.

It sounds like what you've got might work pretty well. I'm curious, does it work when the player app is running? I know there is/was a kernel hack to do sound overlay, and I thought it might have been incorporated into Hijack. That'd be really sweet. Then GPSapp could read directions, for instance.

Also, how is the memory usage? Can you run Flite without swap while the player is running? I was having problems with it when I tried back in the Flite 1.0 days.

I was using flite 1.1 and I'm not sure how to check memory usage.

I tried it while the player was playing and no, it sounds just like DomoKun's date anouncement... so bad that you can't make out the speech. But pausing the player (without quitting), it plays just fine. I haven't tested any large files, just some short phrases. I'd like to see if I can re-compile flite and add a couple features (like upsampling and writing to stdout).

For a GPS app, it looks like it would have to pause the music, speak and unpause. I'm still interested in working towards my initial goal, but I haven't even started on IrDA (which AFAIK isn't in hijack kernels).

Well, actually, I think if it's stuttering, it's probably due to too much CPU usage rather than the sound driver's inability to interleave sounds.

Take a look at this old post. This kernel patch may not have been included in Hijack, but if you patched it in, I think you'd have better results. PCMplay would just have to open the audio device with O_SYNC.

Oh, and to see how much memory flite is using, run the following from a shell prompt when flite is running:

ps -eorss,pcpu,pid,args | fgrep flite

The first column will be the RSS, or resident size, in kilobytes.

In reply to:

---

I tried it while the player was playing and no, it sounds just like DomoKun's date anouncement... so bad that you can't make out the speech.

---

You probably have other 'M' preinit scripts that are being run simultaneously to my TTS Clock program, or you tried R1 of my program. You can rename your other M scripts to B scripts that are alphabetically after B10tts and you will notice that it reads the time flawlessly using an AT&T Natural Voices recording.

Although flite is really cool, I still think prerecorded TTS would produce a better end result then flite can. Compare a recording of flite http://freetts.sourceforge.net/docs/audio/talkforever.wav to a recording of demo of the AT&T voice http://www.naturalvoices.att.com/demos/index.html In car, I think that flite might be very difficult to understand while a voice like AT&T Natural Voices would be much easier to understand. If the price of the AT&T Natural Voices is too much, the free TTS provided by L&H and Microsoft are superior to flite as well http://www.microsoft.com/msagent/downloads.htm#tts

Oh, don't get me wrong, even with flite working I'll still use your ttsclock. It's much higher quality. But flite is already ported to the ARM and runs in the tight memory requirements. For something like a clock, pre-recorded speech is a good solution, but I'm looking for ways to do dynamic speech... e.g. reading directions from a GPS or reading messages that come in on my pager.

If I have ttsclock's startup script called B10tts, it doesn't work because the drive isn't mounted. Named with an M, it's interleaved with the music... I looked at the source for preinit to see about adding a W (wait like the B does, but after mounting), but it forks to wait for the mounting to happen so it's beyond my ability to add such a feature.

Ok, I read the thread. I don't know if I have the patch or not. I'm running Hijack v300 kernel and don't know how pcmplay works... guess that's a no then, eh?

So, the next question is: is there enough CPU power to run flite, decode mp3s and mix the two all at the same time. If not, we may be stuck with running flite to generate temp files and then mix them. That would add a short delay, but shouldn't be too bad.

I'm guessing that both GPS and OBD-II projects can probably pre-precord PCM files with better TTS systems for what they need. I know why I want want TTS, what other uses to people have in mind?

802.11b to your house so when you get close to home, your computer can tell you how many new email messages you have, what new shows your TiVo has recorded and how many files have finished downloading off edonkey?

So, the next question is: is there enough CPU power to run flite, decode mp3s and mix the two all at the same time. If not, we may be stuck with running flite to generate temp files and then mix them. That would add a short delay, but shouldn't be too bad.


That's exactly the approach I'd take. Let flite do its work in the background at a relatively low priority, and when it's complete, play the result.

I have little or no use for the "prerecorded TTS" strategy. The main thing I want TTS for is so my emptriv game can read questions and answers, and provide voice responses to correct/incorrect answers. So on long trips, I can play it without looking at my screen. It would be impractical to generate WAV files for thousands of trivia questions, so real-time TTS is ideal.

I also thought it would be neat if GPSapp used flite to speak directions to the user, and I still think that strategy is better than having to transfer a bunch of WAV files over to your Empeg when you save a route. But since I'm not a contributor to GPSapp, nor do I have a GPS receiver right now, that's not as big on my agenda.

I've gotten a lot of cleanup work done, but I'm not quite ready to release anything yet. I still need to write an install script and some basic documentation.

I've now worked out a couple basic details:
- recompiled flite so it works with the stock libc (upgrading is tricky so it's nice not to have to)
- modified flite so it can write PCM to stdout if asked to.
- modified my pcmcvt to read stdin
- rewrote shell wrapper so now it can read plain text from a fifo.

So the way it works now is that you can write any text to /usr/local/ttsd and it will say it. For example:

sh-2.03# echo hello world > /usr/local/ttsd

This should make it fairly easy to interface with.

Future work to be done:
- pause the player before doing TTS and unpause when done.
- try to integrate upsampling into flite (saves a little ram)
- look into mixing with music
- what to do about generating a wav before reading it... where to store the temp file?

I should be able to realease a beta version tomorrow (well, later today, it's 2am and I'm going to bed) for people to play with.

Sounds cool so far. Looking forward to it.

If you think it'd be helpful, I can try to apply the audio overlay patch to a Hijack v300 kernel. I gave it a quick shot last night but the patch was rejected, so it's going to take some time to manually figure out why it didn't take and hammer it in there... But it should be doable.

I can also hack up a version of pcmplay that will take advantage of the audio overlay. That's a much quicker fix.

Hopefully when Mark Lord comes back we can get him to include the audio overlay support as part of Hijack.

A patched kernel and/or pcmplay would be very helpful!

I seem to recall a discussion from long ago that to play PCM audio on the empeg had some special requirements (like writing a certain block size at a time or something). Is that what pcmplay does? It's the vague memory of such a topic that made me not try to get flite to play audio directly.

Yup. 4608 Byte blocks. Funny number, huh?

Ok, I've finally packaged together a working system. It's 2.5M compressed (4M uncompressed) and nearly all of the size is flite. It's still an alpha release because I haven't had anyone else test it yet. If you're interested, please download it and let me know what kind of problems you find.

Due to the size, you may not be able to extract it on the default / partition (2.5M .tgz + 4M of extracted files is a good percentage of the default size). Suggested installation:

rwm
mkdir /drive0/src
(upload ttsd-1.0a1.tgz to that dir)
cd /drive0/src
tar zxvf ttsd-1.0a1.tgz
cd ttsd-1.0a1
./install

Not too bad, reminds me of the talking moose

Install was almost very simple, had to delete some junk i had in my root directory.

Also, i've attached a sound clip demo of tts working on my empeg.

Edit: Does anyone have a version of top or something similar that works on the empeg?

I had some troubles too.... First I had to create the /usr/local/ and local/bin drectory.... I didnt have them for some reason... and the install script didnt create the folders when needed..
Also my empeg freezes when i try to write something to ttsd... Dont know if everything in the installation went as it should.... I just fixed the two folders...
How much time does ttsd need to speak out the frase "Hello world".... without the player executed...

edit: Now I know what the problem was. As i said earlier I didnt have the correct directorys. My solution was to just create them (/usr/local & /usr/local/bin) But that wasnt enough... I didnt get i to work. The reason for this was that I had deleted the preinit script so that the empeg could boot correctly. And then tried to use the same installation folder as before. But the startupscript wasnt left in the installation folder. So that never got installed again... I had to untar everything again.... and then the installation went perfectly.... and now works!!

Not too bad, reminds me of the talking moose

omg! that's too funny. i had totally forgotten about the talking moose. he was, by far, the coolest thing you could put on your mac back in 1986.

--dan.

First I had to create the /usr/local/ and local/bin drectory....
D'oh. The install script checks to see if /usr/local/bin exists and if not, it creates it... but I forgot that /usr/local may not exist which causes it to fail to create /usr/local/bin.

Also my empeg freezes when i try to write something to ttsd..
Maybe a future version will be better, for now, you have to manually pause it before having it speak. I should have said something about that.

And then tried to use the same installation folder as before. But the startupscript wasnt left in the installation folder. So that never got installed again..
Right now, the installer isn't very smart about recovering from errors... if something goes wrong during install, it doesn't know how to pick up from there and continue installing. That's on the todo list.

In reply to:

---

by far, the coolest thing you could put on your mac back in 1986.

---

Oh Yea, my dad had it on our mac plus! he also used the voice for our answering machine. I would play with that talking moose for hours, clicking on him to hear what he would say

I'd LOVE for my TTS to emulate the voice of K.I.T.T (William Daniels)

Now to just find an 82 Trans Am to put it in

And ironically, my name IS Michael ;-)

Edit: Does anyone have a version of top or something similar that works on the empeg?

Not sure what utils you have installed on yours, but in the absence of top, a combination of ps, sort, and head can serve as a "poor man's top" in the following combination:

ps -eopcpu,pid,args,rss | sort -rn | head -5

.
This will give you the top 5 programs in order of CPU usage. If you want to sort by memory size instead (flite is probably a bit of a memory hog!) do it this way:

ps -eorss,pid,args,pcpu | sort -rn | head -5

.
Or, just untar top out of Frank's ARM debian image.

Thanks Tony,
I'm downloading franks image right now, quick question. Do i have to copy anything else besides top to get only top to work on my empeg?

Not sure. libproc.(something).so probably needs to be in your /lib directory... Give it a shot and see if it complains.

top on my home Linux box wants libncurses too...

~$ ldd `which top`
libproc.so.2.0.6 => /lib/libproc.so.2.0.6 (0x4001a000)
libncurses.so.5 => /lib/libncurses.so.5 (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40065000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/Michael

Error loading shared libraries: libproc.so.2.0.0
After i copy that file to /lib
i get this
Error loading shared libraries: libncurses.so.4 cannot open shared object file
After i copy that file to /lib i get this error
Error loading shared libraries: libncurses.so.4: cannot read file data: no such file or directory.

I remember there being some kinda library link command?

Error loading shared libraries: libncurses.so.4 cannot open shared object file
After i copy that file to /lib i get this error
Error loading shared libraries: libncurses.so.4: cannot read file data: no such file or directory.

I remember there being some kinda library link command?

/sbin/ldconfig

Are you sure that the libncurses.so.4 you copied wasn't a symlink -- to a file the empeg doesn't have? What you're doing should in theory work.

Peter

Ummm I can't telnet into my Empeg here at work, but I'll look at the dependencies and such tonight... Unless someone beats me to it.

My initial guess is that you've got a symbolic link in /lib pointing to nothing, or you need to add a symbolic link somewhere, one of the two.

Edit: Must be a slow day in Cambridge if Peter is here doing tech support!

is /sbin/ldconfig a program? because its not on my empeg

I'm not sure what libncurses.so.4 is. Whatever it is, is 0k in size

Yup, that's a symlink. Just untar the whole /lib directory to some temp directory and copy in everything in that directory starting with /lib/libnc* or something to that effect. That should get the links and the real files.

Do 'ls -l libncurses.so.4' and you'll see if it's a regular file or link

/Michael

I've made a couple updates and now you can download 1.0a2.

Changes since last release:
- now uses flite's 16KHz voice (as opposed to 8KHz)
- has pcmcvt integrated into flite (one less process taking up memory)
- slightly improved rate conversion (still much simpler than a proper rate converter, but it's less CPU intensive... the sound quality difference is akin to scanning one of Mondrian's paintings at a slightly lower resolution)
- directory creation bug fix in the installer

The 16KHz voice increases the size of flite from 4M to 5.9M. Obviously, the size of the .tgz increases as well. This means that it almost certainly won't fit all on your root partition (unless you've enlarged yours). If this is a problem for you, you'll know it when you try to extract the archive, before even trying to run the installer.

If there are any volunteers out there, the installer could use some help... needs to check for errors and recover more gracefully.

I'm also not sure where pcmplay came from. Who wrote it? Where's the source? Am I allowed to hack it apart and reuse the code?