Reading the PhatBox thread got me pretty interested in TTS on the empeg. I'm trying to create a simple program for the empeg that will speak out loud the date and time a few seconds after ignition before the player app starts. I'm trying to do it as a bash script with the help of the pcmplay program and setvol. When finished it can be installed as a preinit script or as a modified init and the empeg can say "Welcome. Today is Saturday November 16. The time is 3:09" a few seconds after you turn on the car.

I've already created all the pcm audio files it would need to string together the sentence. I've used the $200 developer version of AT&T natural voices program to do so using the "Crystal" voice, so its a very high quality tts voice. An online demo of it is available at http://www.naturalvoices.com/demos/index.html

So now all I need to do is create the bash script to string together the sentence based on the date and time. I was looking at http://www.tldp.org/LDP/abs/html/timedate.html#EX51 for info on how to get the date and time, but this just doesn't work under the empeg, probably because it wasn't included with the kernel installation. So does anyone know how to get bash to return the date and time in a script using the empeg? Maybe someone has the date and time command compiled as part of another arm linux package that could run on the empeg?

On a seperate note I could easily create a windows program that would take the empeg database (CSV file) and export prerecorded TTS to pcm, wav, or mp3. I could make it export the name of each artist, album, and title to audio files. I have pretty much all the source code I need to do this in very little time (see my software at www.zabaware.com) It would be minor work for me to read in the CSV file to export all the fields as audio files.

But I don't have enough linux experience to be able to write any useful TTS app for the empeg. But knowing that I volunteer to make a windows program that creates prerecorded TTS audio files based on any set of data, is there any linux programmer out there interested in creating some usefull TTS app for the empeg?

Don't recall where I got it, but I've attached the `date´ binary to this post - hopefully it survives without any CRLF translations mucking it up.

Assign the string returned by the date command (encolse in back-ticks) to a variable and parse out the parts (or make repeated calls with different format parameters to get the various parts). The man page for date is here.

In general, deb-packages (they're 2 tar.gz files ar'ed together) can be found via the Debian homepage, http://www.debian.org

/Michael

In reply to:

---

On a seperate note I could easily create a windows program that would take the empeg database (CSV file) and export prerecorded TTS to pcm, wav, or mp3. I could make it export the name of each artist, album, and title to audio files. I have pretty much all the source code I need to do this in very little time (see my software at www.zabaware.com) It would be minor work for me to read in the CSV file to export all the fields as audio files.

But I don't have enough linux experience to be able to write any useful TTS app for the empeg. But knowing that I volunteer to make a windows program that creates prerecorded TTS audio files based on any set of data, is there any linux programmer out there interested in creating some usefull TTS app for the empeg?

---

Hi, interesting ideas, if you were to create PCM versions (at 44.1Khz sample rate), of all the songs in the CSV file, then you could esaily output these on the empeg as the DSP takes PCM files, and the pcmplay (and setvol) utilities can be used.

Note, if you name the PCM files using the FID of the tune (which I assume is available in the CSV file format exported by Emplode - if not then the XML version has FIDs in it), then it is easy to find the FID of the currently playing song, so you could then "mix" the PCM audio pre-spoken title of the song in to the audio stream.

However, that won't help with the speaking while browsing capabilities that the phatbox has.

The long term solution is to have a TTS engine on the Empeg, but that may require a lot of CPU for a real time spoken song titles as they play solution.

However a interim step may be to have a "on empeg" TTS engine and have it run automatically (or manually) run anytime that the tune database changed to rebuild the spoken title/playlist database. (i.e. do what emplode does during its database rebuild but for the spoken track names.)

There's something to be said for TTS on the PC vs on the empeg. It would remove the overhead of processing each time the FID is referenced, which since the output is going to be the same each time is just wasteful of CPU cycles.

Another advantage is that it would give users the chance to preaudition and correct pronunciations before download - making a 'live' TTS behave differently for a particular trackname isn't going to fly. (That could be gotten around by using a different field to trackname... (eg a 'SayAs' field) as the TTS input, but audtioning and changing this field could be tiresome...unless the TTS engine was also on the PC, which is duplication that could be avoided..)

Sure, the first time that you enabled TTS would involve a long TTS translation and download process, but after that, adding TTS prounciations for newly added tracks would be relatively painless.

Thank you very much for the date binary. I have now completed the bash script now and it works very nicely. It is available for download at http://www.zabaware.com/empeg if anyone is interested in installing this on their empeg. If anyone notices any bugs or has suggestions please tell me.

Even if someone managed to port a linux tts engine such as festival to the empeg, I still think that prerecorded tts is a better solution. You pretty much know in advance what its going to say so there is no point in forcing the cpu to do that. And also tts voices for windows are currently of higher quality then the linux ones, especially the AT&T natural voices and even the voices by L&H, IBM, and Microsoft.

The CSV file does contain the FID for each song, so pcm files with the same FID can be created. I believe in order to get TTS to work on the empeg just a few changes need to be made to hijack:
1. It would need to monitor what the current song playing is
2. When the song changes to a new song it should see if a pcm file with the same FID exists in the tts folder (the tts folder should be a config.ini option)
3. If a pcm file for that FID exists it should send the pause key to the player to prevent the new song from starting right away.
4. It should then play the pcm file.
5. After the pcm file finishes playing it should send the pause key to the player again to resume playback of the song.

Well if anyone is willing to handle that linux side of this give me the word and I'll have the windows side of it (CSV to TTS to PCM) working in less then a week:

The actual text spoken in the pcm file, the voice engine and font used, and the speech tempo will all be customizable by the user. So one person can have the female British English from L&H say "Now playing %title% by %artist%" and another user can have the "Mike" voice from Microsoft say "Playing track %track% from %album% by %artist%. %title%" It will also give the option of teaching it to pronounce certain words that it mispronounces.

Most engines except the ones by IBM and AT&T as far as I know are capable of writing the TTS to a file much faster then they normally speak. So it actually shouldn't more then a couple of minutes to convert the CSV music database into PCM files.

Also, most TTS engines for windows have a 11Khz sample rate, with some being at 8, 16, and 22Khz. They are all mono. If someone could make a version of pcmplay that can play 11Khz mono instead of 44Khz stereo that would save a lot of wasted space, the file size of the pcm would be 8 times smaller and there would be no change in quality.

What is the interest level in the empeg community to getting TTS as I described working?

I tried but it didn't seem to work very well for me.

I hear "Welcome. Today..." by then the player has started playing. The text can be heard stuttering over the music. The player also seems to go slower while it stutters.

Tom

I actually installed it as a custom init on mine without the aid of preinit. I looked through the preinit documentation and saw my mistake. Preinit doesn't wait for 'M' scripts to execute before launching the player. 'B' scripts are for that. Rename the file M10tts to B10tts and it should work. I'd reccomend testing the script from the command line before rebooting to make sure it works, because if something is wrong with a 'B' script it would render it unbootable and force you reflash the kernel. Make sure the script has permissions and just type "B10tts" and it should speak the time and return to the bash prompt. If it works then you're safe to reboot.

I have posted an updated version so all downloads from now on will have the file as a 'B' script.

Ok, where is Mark Lord at? :-)

Ok, I posted a new version of the TTS Clock program at http://www.zabaware.com/empeg/ that fixes several bugs. Sorry about the bugs, I should have tested it a little more before I posted it. Everything should work fine now.

sh-2.03# ./B10tts
/dev/empeg_state: Device or resource busy
cat: /drive0/var/tts/month07.pcm: No such file or directory
cat: /drive0/var/tts/: Is a directory
cat: 8th.pcm: No such file or directory

I tried renaming the month7.pcm to month07.pcm and that part worked fine, but it still didn't say the day and still got the error for8th.pcm


And yes I know my date is wrong, one thing at a time

My other problem is, drive0 is not mounted yet when this script is being exectuted. I can only run this manually.

From more testing I renamed B10tts to M10tts and it runs, but I don't hear anything. It runs fine manually still.

Another problem is it reading from the 24 hour format (14:11 reads as "Four Eleven")

I'd actually prefer to have my empeg read in 12 hour format, but can't seem to figure out how to do that. I set it in the settings to 12 hour, but in setting the time it still shows/allows me to set in 24 hour format.

A feature that goes along with this would be to say "PM" or "AM" at the end accordingly.

I posted a newer version of the script at http://www.zabaware.com/empeg/B10tts and updated the zip file. It now works when month is < 10 day is < 10 and hour < 10 and minute < 10. You can rename the 08 file back to 8. Be careful of CRLF translations if you just download the script instead of the whole zip.

I already had a custom init without preinit installed, so I'm not actually using preinit. I'm just adding this code to my modifeid init and it works for me. Can anyone tell me more about preinit? If B scripts are run before mounting and M scripts are run concurrently to the player is there any other type that will run after the disks are mounted but force the player to wait until it finishes executing? Or should I just add the mounting code to the B script?

I added mounting code to the B10tts script and updated both http://www.zabaware.com/empeg/B10tts yet again and the whole zip package at http://www.zabaware.com/empeg/

I haven't actually tested it though as I don't have preinit installed, but I think that it should work.

That code did work, Thanks!

Yet another problem..

It tried saying the time for 5:09 and all it got was "five o"

the error it generated was:

./B10tts: let: 09: value too great for base (error token is "09")
./B10tts: let: 09: value too great for base (error token is "09")
/dev/empeg_state: Device or resource busy
cat: /drive0/var/tts/09.pcm: No such file or directory

just a little FYI for myself, whats it trying to do and what goes wrong when it says: /dev/empeg_state: Device or resource busy ?

ok, i'm noticing something strange. I had the time set to 15:35 and the clock format set to 12 hour. Rebooted and everything was working great with correct time. Rebooted again, still fine. Rebooted again, The time displayed is correct, setting it is correct, but the TTs is reading "five thirty five". Going in through telnet and creating a directory gives it the time of 17:35

Whats going on? I don't think this is an issue with TTS, but with empeg clock issues?

Its seems the line "let minute=minute+0" is not a viable method for converting "09" to just "9" Its causing the "value too great for base" error and is the reason it didn't say the minute for you. I'll have to come up with another method to do that and I'll post an update here shortly once I do that.

As for the message "/dev/empeg_state: Device or resource busy" I think that is something Mark Lord's setvol program is saying, which could be a big problem. I don't get that message in my custom init. The setvol program is trying to read what the volume was set at when you last turned off the empeg so that it can use that volume level. If its not able to read it I'm not sure what level its setting your volume to. In DC car mode it might keep the volume at 0% and you won't be able to hear it, or possibly it might set it to 100% and blast your head off. Can you run setvol from the command line with no problems?

And as for it being 2 hours behind that is because the player software has its own timezone setting that this program can't read. The only way around this that I see is to set your timezone as "Universal" or "UTC" in the empeg player app and then set your clock accordinly.

Ok, so far setting it to Universal Timezone seems to be working ok. We'll see how that stays.

I tried running the setvol binary manually and get the same error: "/dev/empeg_state: Device or resource busy"

Not sure if you saw my suggestion/request in one of my previous posts about it saying AM or PM at the end of the time. Is this do-able?

Sure, I'll add AM/PM to it.

I'm a little stuck right now with the error when the minute is 9 or 8. The funny thing is if the minute is 0,1,2,3,4,5,6, or 7 my method of removing the extra 0 works. But when the minute is 8 or 9, it produces an error.

Try this command at the bash prompt:
echo $(( 03 + 0 ))
That will return 3

echo $(( 07 + 0 ))
will return 7

but
echo $(( 08 + 0 ))
will return 08: value too great for base (error token is "08")

and
echo $(( 09 + 0 ))
will return 09: value too great for base (error token is "09")

Can anyone think of an alternate method of removing an extra 0?

Can anyone think of why setvol doesn't seem to work for leftyfb?

A number that starts with a zero is interpreted as being in octal. I haven't really looked at your script to tell you how you should be solving this problem, but that's the cause of this error.

Edit: However, if you've got a variable, let's say $i, that's in the form 00, 01, 02, ..., 09, 10, 11, ..., and you want to strip a possible leading zero, then using the expansion ${i#0} would be the best way.

Remember, that if you are using rsync, make sure you set up the script on the empeg to exclude the three files in /drive0/var and to exclude the tts directrory

--exclude=date \
--exclude=pcmplay \
--exclude=setvol \
--exclude=tts \

The above works for me.

Oh and I am really enjoying the app.

I've installed your app but I am not setup to listen to the player indoors, doh! Everything appears to work ok, at least, my player doesn't crash etc. Here's hoping for wry smile when I dock the player in the car tomorrow morning on my way to work, thanks

Anyhow, the real point to my post is..... Have you received any offers of help with the Linux part of playlist TTS yet or has there been any further developments there on your part? You KNOW you want to become a Linux programmer don't you

Thanks for the code. I've now updated the script so it can now say August, September, 8 AM, 9 AM, and the minutes 08 and 09 because there was a bug that prevented it from speaking those particular numbers. It now also speaks "AM" and "PM" outloud.

It is available as TTS Clock r3 now at http://www.zabaware.com/empeg

For people that already installed a previous version if you don't want to download the whole package again you can just update the script which is at http://www.zabaware.com/empeg/B10tts (be careful of CRLF) and add the AM/PM sounds to the TTS folder which are at http://www.zabaware.com/empeg/am.pcm and http://www.zabaware.com/empeg/pm.pcm

In reply to:

---

Anyhow, the real point to my post is..... Have you received any offers of help with the Linux part of playlist TTS yet or has there been any further developments there on your part? You KNOW you want to become a Linux programmer don't you

---

No one has offered to help out with this yet, but hopefully someone does soon. I'm slowly but surely learning my way around Linux, most of which I can attribute to the empeg One of these days I'll have to try setting up a cross compiler to see if I can compile something for the empeg in c++

This is great!

It all works just fine now.

Thought of another idea. Instead of welcome, maybe from midnight to 11:59am it could say "Good Morning", from Noon to 6pm "Good Afternoon" and from 6pm to Midnight "Good Evening" ?

It won't work for me. As in, it is always AM. What did I do wrong? I saved the script onto the empeg and put the am.pcm and pm.pcm files in the tts folder.

You know, upon futher testing (setting the correct time AGAIN), it is always saying AM on mine also.

In reply to:

---

You know, upon futher testing (setting the correct time AGAIN), it is always saying AM on mine also.

---

Fixed it! As always the updated script is at http://www.zabaware.com/empeg/B10tts and the updated package is at http://www.zabaware.com/empeg

PM now works. (this guy is good )

But alas, another bug. "Welcome, today is Monday, November 18th. The time is clock:43PM" As opposed to 12:43PM. I tried copying 12.pcm to 00.pcm with no luck. So much for trying to fix it myself this time

Speaking the song title of the next song to be played would kind of be annoying. I don't see much point in getting TTS working and having a wave file per FID. Imagine hearing the track names spoken in between the tracks of "Dark Side of the Moon". Ick.

On the other hand, TTS for browsing the Playlists would be rad. I believe that would take a change to the player software, though. It would be weird to hear the menu being spoken over a song, though. A TTS enable/disable function would be needed, because sometimes you would like to hear the TTS while browsing the menu (picking playlists on the fly) and other times you don't (EQ settings, etc.). I could even see an option of pausing the current playback while browsing with TTS.

I believe that would take a change to the player software

Nah, we just need Mark to add OCR functionality to the kernel to read the current menu item and then pass the text to the TTS engine...

...only kidding Mark !



P.S. It wouldn't actually need to be "proper" OCR as the characters will always be perfectly formed on screen, so it is more screen scraping than OCR.

Ive tried to install the tts program now and i dont get the permissions right..... When i try to chmod the date/pcmplay/setvol files i get "chmod: date: Read-only file system"
Allthoug i have used rw.... and then i used rw /drive0 (dont know if thats possible.... but it was a try) rw command works.... but i still cant chmod the files.... I cant get it why it doesnt work.... it should....
Then all of a sudden i lost all contact with the empeg over ethernet.. allthough the kftpd has started´and listens to port 21.. dont think this has anything to with the tts though....

ahh.... i just figured out the ethernet issue.... According to norton internet security the empeg tried to connect to a trojan horse port.... and therefore has been banned.... It worked out when i added the empeg as a "trusted site"....

Cant still get the chmod to work....

well....... I guess i solved now....I used the chmod command through ftp instead..... wich worked out just fine.... still cant figure out though why the hell i couldnt do it through the command shell....

rwm

In reply to:

---

And as for it being 2 hours behind that is because the player software has its own timezone setting that this program can't read. The only way around this that I see is to set your timezone as "Universal" or "UTC" in the empeg player app and then set your clock accordinly.

---

I wouldn't do that, because you'll lose DST switching and you'll also lose easy country adjustment when you travel abroad. Instead, set the TZ environment variable in the shell you're running your code from (and export it, of course). (I assume tts-clock uses localtime(), not gmtime()).

If I set the TZ in the player settings to Eastern, and reset the time, it shows fine on the player, but tts says the time 5 hours ahead, along with the actual time of the OS being 5 hours ahead. I check this by telneting in and creating a dir, the time for it is set 5 hours ahead. So I don't think this is a tts problem, but with the players inability to change the timezone for the linux OS but only for itself?

Yeah, when I looked at it the default libc on the empeg is looking in the wrong place for timezone files. It should be possible to work around that by adding

export TZDIR=/usr/share/zoneinfo
export TZ=EST

to a .bashrc, or the top of whatever script you start.

well seeing as i'd like the TZ to be correct for the whole system (player software and OS), would it be possible to create a link pointing to the correct place?

So if I'm understanding right, the player software is changing a file that the OS doesn't use to determine it's Timezone? Then making a link to it will allow the setting in the player software to change the time for everything?

Hi, I just installed your tts welcome script. It worked great. Directions were very easy to follow, even though its not that difficult. I tested the program before i rebooted the empeg, and it worked great. However during startup she stutters pretty badly I've attached an MP3

Edit: DoH! too big Click here for the mp3

The TTS Clock program reads the local time from the operating system, not the UTC. But the local time is set to UTC for some reason. So if you manage to change the operating system time zone the TTS Clock will use it.

Hmm, thats strange. In my first release, I had it as M10tts instead of B10tts. It should be a B script so that it doesn't run concurrently with anything. If you happened to install the first version did you make sure to delete the M10tts before putting on the B10tts? Do you have any other M scripts running? I think that since my B script mounts the drives that other M scripts might be launched simultaneously to the B10tts script.

If you do have other M scripts, I think that since my B script mounts the file system you can rename your M scripts to a B script that is alphabetically after the B10tts script and it should work.

I have posted TTS Clock R4 at http://www.zabaware.com/empeg

This new version fixes the problems it had with saying AM/PM correctly at 12 PM and 12 AM. It also replaces saying "Welcome" with "Good Morning", "Good Afternoon", or "Good Evening" based on the time of day.

If you have a R3 and don't want to download the entire package you can get the updated script at http://www.zabaware.com/empeg/B10tts and download the 3 new pcm files http://www.zabaware.com/empeg/morning.pcm http://www.zabaware.com/empeg/afternoon.pcm and http://www.zabaware.com/empeg/evening.pcm

All set now, updated to r4, changed my telnet, and launcher scripts to B scripts. Now everything sounds great!

The good morning/evening is a very nice touch!

Now i'm having the same time problem as everyone else, my clock is set correctly, tz is set to eastern, player shows the correct clock, but the system clcok is 5 hours ahead. Anybody figure this one out yet?

so far i've found two articles on how to change the system timezone

here and here

The system was setup so there was a link called localtime in /usr/share/zoneinfo pointing to a nonexistent /etc/localtime. So I created a a link: /etc/localtime to point to /usr/share/zoneinfo/US/Eastern .. thus making the /usr/share/zoneinfo/localtime link valid. Also as one of those articles points out I create the link: /usr/share/zoneinfo/posixrules to point to localtime (renaming the already existing posixrules to posixrules.disabled).

All of this and so far no dice .. gonna play with it a bit more.

Upon examination of the posixrules file (vi) I found one of the only readable texts in it "singapore" ... i'm wondering if this was the default TZ or something.

Let me set everyone straight on Unix timezone stuff.

The kernel has no real concept of a time zone.

On most Unix systems, the default time zone is set by init. It does this by setting the TZ environment variable in its own environment. Since all processes are children of init, all processes inherit that TZ environment variable.

However, when a process is run, it doesn't make any difference who set the TZ variable that it inherits.

On the empeg, the init process is not the init process that is going to be on most general purpose Unix systems. It does not (I'm pretty sure) deal with the time zone at all. This has the effect of setting the ``system'' TZ to UTC.

The time zone that you set in the player changes the time zone for the player. I don't know if it does this by setting the TZ variable or if it deals with figuring the local time itself, but it doesn't really make any difference, since no other process will ever use that setting (unless you could get the player to fork a new process).

I'm not really sure what you're trying to achieve here, but if you want to be able to record the local time zone, then you're going to have to figure out how to do it for your process. It might be possible for preinit to set the time zone by reading in a configuration file, and it would actually pass that to init, but I don't know what it might break by changing the player's time zone. It might make a dual offset, or it might do the right thing. I don't know. Preinit cannot do this now, but it wouldn't be too hard to hack it in.

HTH.

Does anyone know where the empeg player app stores its time zone settings? If its easily readable by grep or something like that I could modify the TTS Clock to read the timezone and compensate for the correct hour.

I've also just noticed that, on ac power, the volume doesn't set in the player to the last volume setting, but the setting from the time player. Is there anyway that this can be fixed?
I haven't tested this on dc power, i haven't let my office yet, but i will soon.

does anyone have a sample of the script as a wav file. im curious how it all sounds together.

btw, your first mention was to include the drivers name in the good morning, is this still a possibility i take it. seems like it would be pretty straight forward.

here you go

I know youve talked about the TTS to eventually read the menu and song/playlists. But that requires some new features in hijack right?.... Wouldnt it be possible to use one of the input ports on the new Tuner II.....( I seem to remember there was going to be 2 extra availeble inputs) to hook up a mic so that we could have speech commands. Like next/play/pause/mute and so on.... I guess the port is to slow perhaps.... Dont know the speed of it, or the requirements to get good speech recognition....
But its one idea i would love to see get bourne into reality...

The player already has a mic input for just such a purpose, there's just no software to use it.

Recognizing even just a short list of commands like that is relatively complicated, especially in a non-ideal environment... accents, noisy road, music playing, maybe you drive a topless car, knowing when you're talking to the Empeg and not to your wife about pausing for a moment to think about your daughter's play next week, etc.

"What is the interest level in the empeg community to getting TTS as I described working? "

I'm all about this app.... lets do it! I will help out anyhow I can!

Is there a way to fix the volume to -12db while in the car? sometimes i leave it at -3 for music, but that's way too loud for the program's voice, it's ripping my speakers!

i had to type:

literal site rw
literal site chmod 755 [filename]

i had to add "literal site" before my commands at my dos prompt, ftp shell.

im interested as well. writing the windows application to generate the wav files of your directory structure is the easy part and i think step 1. but interupting the basic function of the player to play these wav files might be difficult. isnt that stuff closed source? someone with experience might know. If this isnt and issue than i think we might have the ability to get started soon.

You can edit the the B10tts with a good text editor to set a fixed volume. First, I reccomend using an editor called UltraEdit (don't convert to DOS mode). Its available from www.ultraedit.com You can do it with notepad, but it is hard to read as it doesn't show the Unix style line breaks as line breaks but as boxes. Find the line that says:

/drive0/var/setvol

and add a number after it to set the volume, for example:

/drive0/var/setvol 40

will set your volume at 40% (I don't know what db level this corresponds with, play around with it)

In reply to:

---

im interested as well. writing the windows application to generate the wav files of your directory structure is the easy part and i think step 1. but interupting the basic function of the player to play these wav files might be difficult. isnt that stuff closed source? someone with experience might know. If this isnt and issue than i think we might have the ability to get started soon.

---

I don't think it would be too hard for someone that has more progamming experience then me. The program hijack already does a lot of things with the player app without access to its source code. In order for TTS to announce the name of a song that is about to play all that it would need to do is monitor the filesystem for an FID file to be launched by the player app. When it detects it, it could send the pause key to the player, making the player think someone pressed the pause key. While it is paused it would play the prerecorded TTS file associated with that particular FID. Once the prerecorded TTS finishes playing, it would send the pause key to the player app again to resume playback of the MP3 file.

It's actually a lot easier than that. Hijack doesn't have to monitor the file system, everything needed (artist, title, etc.) is available in /proc/empeg_notify.

Though having a prerecorded TTS file for every song on my empeg seems a little... um... wasteful. I dunno.

I don't even understand the concept of wanting to have each song announced. I mean, it says what the song is right on the screen. How long does it take to read that? You know what it is anyway.

But whatever.

In reply to:

---

Though having a prerecorded TTS file for every song on my empeg seems a little... um... wasteful. I dunno.

---

The voice I used for this TTS Clock program is actually only 8khz at 16-bit mono. We could probably figure out how to upsample this in real-time.

I'll use my library of songs as an example to calculate how much space would be requierd. Assuming you have a library of 4000 songs, and assuming it would take the TTS an average of 6 seconds to announce the title and artist, that would be 240000 seconds of speech. In 8khz 16-bit mono PCM format that would 368 MB to store the prerecorded speech. Yeah, that is a pretty large footprint, but I still have 15GB free on my 40GB player, so its not really that much. I think its worth it to get the highest quality TTS voices working on the empeg.

And if we use some compressed audio format instead of raw pcm, I think the footprint for this would be almost unnoticable.

I mean, it says what the song is right on the screen. How long does it take to read that?

Well considering you're in a moving vehicle, maybe "too long?"

I dunno. I don't think it's a *superb* idea, but sometimes I'll have to look at my display a lot to tell what song is coming on, mainly if it's the kind of song that fades in or doesn't start off with anything discernable (ambient sounds, etc.) I've caught myself thinking it might be nice to have the artist/title announced, but I also think it might be annoying after awhile.

In any event, I am more interested in TTS for the trivia game, and pre-recorded TTS would seem to be a bad idea there.

Yeah, I'm with you there... I don't want to take away from the achievements being made here, but I just can't see the attraction of song announcement. Didn't I stop listening to the radio because of all the stuff that wasn't music?!

That all being said, I think that this would be very useful for playlist browsing, and also for 3rd party apps such as emptriv and GPSapp. Unfortunately I can't see an easy way to make this work for playlist browsing without some support from the Empeg guys in Cambridge. But maybe this effort will help persuade them to do that...

I can also see use for this being called from HJ as an audio version of the 'Details' screen...Press the button and it tells you the trackname, author etc, going through all the details 'til you press the button again to stop it (or it runs out of data). I think I would find that useful..

In reply to:

---

I don't even understand the concept of wanting to have each song announced. I mean, it says what the song is right on the screen. How long does it take to read that? You know what it is anyway.

---

I'll explain my reasons for wanting this so much. I live in Erie, Pennsylvania by Great Lake Erie. We get a lot of "lake effect" snow. We get snow from November to March and a lot of it. I have ahead of me 5 months of driving through snow, ice, slush, and blizzards. I cannot afford to look at my screen for even half a second without risking a serious accident. And even in the summer I have had many close calls looking at my screen waiting for the artist and title to scroll by when I should be looking at the road. Having a library of 4000 songs I simply can't remember what the title of the song or often even the artist is. And even for songs I have heard hundreds of times I often forget the title. But I really want to know what I'm listening to so I would find this a very useful feature, I wouldn't think it to be annoying at all.

from reading the post about the phatbox it seems they they only announce when traversing playlists.

So its not that it will pause and play, next song is <fill in> but when you go to change what playlist is being used it will annonce the name. i think this is what we should target first. and i think the footprint would be small.

To me this is much more usefull and would actually be quite nice. when you want to change what playlist it is using you can do it via push of a remove button and it will read of the playlists as you go through them and you dont have to look at the player.

I totally agree re: snowstorms/weather. It's a safety thing for me. Although, the gee-whiz power would be immense. I'm not a programmer so the 'how' of it isn't too important, half a gig of non-music doesn't bug me in the least.

I'd like the ability to switch it on/off separately for directory navigation and song announcement. I think some may like one, the other, neither or both & so be able to pick via a hijack menu, like voladj.

I'm really excited to see what you guys come up with. I'll wait till it's ironed out a bit first, I'm not very adventurous.

I'm psyched!

-Zeke

I went back and reread what I wrote and it was pretty pissy. I didn't mean to come off like that. Sorry.

OTOH, I understand where you're coming from a little better now. What would be very cool is if you could set it up so that a specific button press would announce the current song. That way you wouldn't have it saying ``Tequila'' and you saying ``Duh!'', but you could request that it say ``Train to Nowhere''.

I thought of another neat feature/use for TTS. Coupled with OBD it could tell you things like your due for an oil change, or when certain fluids are low(gas, oil, tranny, etc.) I'm sure there's lots of other info that can be pulled from OBD that i'm not thinking of that could be periodically (configurable) announced.

In reply to:

---

So if I'm understanding right, the player software is changing a file that the OS doesn't use to determine it's Timezone?

---

The player software shouldn't be modifying files (except when doing a sync, of course). It keeps its own choice of timezone in flash memory, and uses that in conjunction with the TZLIB files to calculate (in libc) the local time for the process.

I'm not sure what you mean by setting a timezone for "the whole system (player software and OS)" - the OS doesn't have any concept of timezone. Timezone is a user-level concept that the kernel doesn't need to know about in order to do its job. Remember that the player's OS is taken from a general-purpose system, where many users may be logged in from different physical locations, and therefore having different timezones in their processes. It's quite common on desktop systems to run two copies of xclock (or similar) in different timezones if you work closely with colleagues in another country.

The issue that arises is that while most programs can read the TZ environment variable to know what timezone to display times in, the player needs a way to change, store and retrieve a user-set timezone, and obviously an environment variable is not suitable for this, as it's not persistent beyond the process. It can't be set in config.ini, as a user may cross timezone boundaries on his or her travels (I'm sure I'm not the only one who's done this). However, reading from config.ini to set TZ in the environment for other programs is probably reasonable for add-on programs, unless we can discover where the player stores its setting.

That last sentence is a challenge to someone, I hope.

In reply to:

---

The player software shouldn't be modifying files (except when doing a sync, of course).

---

If the player isn't modifying anything on the OS side, then how is it setting the time for the OS when I set the time in the player settings?

Basically what i'd like to see (if possible) is the ability to set my timezone in the player software, set the time,and have the player software and the OS time be in sync.

I can tell that right now when setting the time in the empeg settings, the time is getting changed both in the player software and the OS side. I check this by telnetting in and creating a dir and looking at the time it was created. This time is getting set by the player settings, but since the player is using EST and the OS apparently is not, the time is 5 hours off. Unless I set the player TZ to be Universal in which case both are in sync. But as someone else said, this won't account for DST and I think minor other problems down the road.

This will also help with the TTS-clock in it's current state as it is pulling the time from the OS, not the player software. I also think if we are going to pursue further userland apps that will be running on the OS(GPS), the OS time/ZT being in sync with the player software might become more crucial.

In reply to:

---

If the player isn't modifying anything on the OS side, then how is it setting the time for the OS when I set the time in the player settings?

---

That's not modifying files (see - I was careful with my words!). The RTC, like the flash memory, is writable all the time (to a process with sufficient privilege). But remember that even though the player is showing you local time, it's talking UTC behind the scenes to the kernel. I hope this explanation makes sense.

Absolute (UTC) time is a global concept in Unix; the translation of that time to a particular time-zone is each application's responsibility (just as providing messages in the user's language is). Most applications use the library function localtime() which depends on TZ (the environment variable), so they all have the same behaviour. The player software (probably) doesn't use the environment variable, as it keeps its own time zone in persistent (but not file) storage.

I agree that it would be nice for TTS-clock to pull the player's time zone setting from flash memory (or the scratch partition?) and use that, ideally doing so each time it's used. That's what I was hinting at, at the end of my previous post. A skilled empeg hacker (i.e. not me!) might be able to reverse-engineer the player's actions in response to the user's selection of a time zone, by intercepting the right system calls, I think.

Ok, so basically every app running on this would need to (if based on time) set it's own TZ either through a variable to however the player software is doing it? So in the case of checking the creation times of the directories created in telnet, the telnet daemon would need to set it's own TZ or in the bash shell(is that the shell we're using?)?

EDIT: or better yet, as someonle else mentioned previously, everying is a child off of "init". Should we be setting the TZ variable in there, that way everything (that can/will use it) is using the same TZ?

I just thought of another neat feature. If there were a thermometer that could be tied to the serial port and places around the vehicle somewhere, it could tell the current temperature. "Good morning, today is Tuesday, November 19th, the time is now 12:41PM. The current temperature is 14 below zero"

Another stretch (maybe annoying) would be to sync top news headlines and have it read them off on your way to work if you feel so inclined. And maybe if you find a headline you like, press the knob and have it read off the entire article.

This all of course being after the empeg has completely booted and with the music muted.

In reply to:

---

Ok, so basically every app running on this would need to (if based on time) set it's own TZ either through a variable to however the player software is doing it? So in the case of checking the creation times of the directories created in telnet, the telnet daemon would need to set it's own TZ or in the bash shell(is that the shell we're using?)?

---

In principle, yes, each application should do its own timezone processing based on the player's setting (assuming we find where it's stored, of course). In practice, it's straightforward to do so if we can change the implementation in libc that most applications use. We're straying out of my ability here, though!

Using init to set the TZ variable would be a reasonable halfway house. After changing the player's timezone, it wouldn't have any effect on other apps until your next boot, though. I guess most people could live with that.

After changing the player's timezone, it wouldn't have any effect on other apps until your next boot, though.

That's actually the way it is on most Unix systems.

Ok... this project was the first time I had ever FTPed anything to my empeg. Pretty fun, and it worked... except that it reads the time five hours early. I checked my empeg clock and my time zone. This is probably simple...but so am I .

anyone got this error from B10TTS?

mount: proc already mounted
mount: /dev/hda4 already mounted or /drive0 busy
mount: according to mtab, /dev/hda4 is already mounted on /drive0
mount: you must specify the filesystem type
/dev/empeg_state: Device or resource busy

yeah.... I was just about to comment on that one... Seems to me that the B10tts starts 2 times. One time when it should with preinit.d And one time later just before the player starts.
I added my own startup script to have emptriv start at boot. Its a M10 script and since I added it, TTSclock starts twice. First I used the & command behind my M10 script... Wich resulted in TTSclock speaking twice before the player starts. And without it, TTSclock starts the second time when the player is executed. If I delete the M10 script the problem disappears. I had the same problem when using a M10 preinint script with TTSd (flite).

for me, it doesnt start at all. i dont hear sound or anything.

In reply to:

---

for me, it doesnt start at all. i dont hear sound or anything.

---

That makes two of us...
Anyone any ideas?

Check the permissions of the B10tts script? It needs to be executable.

actually i massaged it to play, but now it doubles up.

In reply to:

---

mount: proc already mounted
mount: /dev/hda4 already mounted or /drive0 busy
mount: according to mtab, /dev/hda4 is already mounted on /drive0
mount: you must specify the filesystem type
/dev/empeg_state: Device or resource busy

---

The B10tts script must mount the partitions during bootup. If run from the command line after its already booted it will give the already mounted errors, but nothing bad happens. During bootup your normal init will give you the already mounted errors since B10tts will mount it before init is run, but this is ok also.

As for "/dev/empeg_state: Device or resource busy" that is the setvol program trying to set your volume. I don't know why you are getting that, but if your script works from the commandline, but not during bootup this could be the cause. It is supposed to set the empeg volume from 0 to whatever you had the player volume set to. If it doesn't work the volume will be 0 and you won't hear anything.

Earlier in this thread I mentioned problems with having 'M' scripts on your system with my 'B' script. If you have my B script loaded and you have other M scripts, you should rename all your M scripts to B also to prevent the program from stuttering. Make sure they are alphabetically after B10tts.

did anyone else notice it wasn't able to say "21st" this morning?

If you have my B script loaded and you have other M scripts, you should rename all your M scripts to B also to prevent the program from stuttering. Make sure they are alphabetically after B10tts.

I've noticed that that's a problem, but why is that? At first glance, it would seem to be a bug in preinit, but I can't tell for sure.

In seting up ttsd, I named its startup script M10ttsd because it needs access to files. For people with both ttsclock and ttsd, it needs to be called B20ttsd. That would then mean that my installer has to check to see if ttsclock is installed so it can name ttsd startup script accordingly. Conversely, if ttsclock is installed after ttsd, then ttsd's script needs to be renamed.

Is there a better way to do this?

I only ever intended for there to be one B script. It stands for ``block'', which means that it's intended to block at the end of the script, probably by running the player itself.

If you're not going to do that, there should be no functional difference between an N and a B script, other than they run as two separate queues.

Ah, I've never had more than one B script so I've never really played with that.

I'm still not sure I understand why the B script gets run a second time when there's an M present. After ttsclock runs (B10tts) and says the time, then ttsd runs (M10ttsd) which includes a 10 second sleep. After the 10 second sleep, M10ttsd finishes and B10tts is run again and tries to say the time while the player is now playing. I would have expected each script to only be run once.

That's probably a bug, but I never caught it because that's not the way I intended it to be used. I'll take a look at it.

Me too! Me too! This morning I thought "maybe" it didn't say '21st', but I at lunch today I know I didn't hear it.

-Chuck

did anyone else notice it wasn't able to say "21st" this morning?

Yes, same here.

yeah.... me too..... this is my output:
./B10tts: [: &day: integer expression expected
Saved AC volume was 86
Volume=86
cat: /drive0/var/tts/21th.pcm: No such file or directory

The path is correct.... My guess is that youve kinda forgot that date?

I think that B10tts has a typo:

There seems to be a simple typo in this line which I guess is making the test NE and fall through to the Else statement:
if [ "$day" -gt 20 ] && [ "&day" -ne 30 ]

I'll try it later if I can remember how to drive Joe/Vi/whatever-it-is-editor

That fixed it. Thank you for having a good eye.

-Chuck

yeah... that solved mine too....
I have installed Tonys modified kernel with the audio overlay patch... I also renamed B10tts to M10 tts to get it to read while playing... it worked.... But its lots of lag.... it speaks... then the player takes over.... then it speaks again..... and so on.... I guess its a question of priority..... but how do i change tha?

I'd really like to have the Audrey (UK English) voice from naturalvoices.com for my TTS - can you give me any tips please, especially on how I convert sound to PCM format in Windoze and sample rates etc?

TIA.

I used the program Cool Edit 2000 from www.cooledit.com to write all the PCM files, although I'm sure there are many other programs that can do it also. When you save your PCM files you just need to make sure they are 44.1khz 16-bit stereo. You can open up and listen to the PCM files I created in cool edit in order to find out everything that needs to be recorded. If you setup your windows audio mixer to record "wave" or "what you hear" you can record the output of any program into cool edit. Then you can clip out parts of audio in order to get each word into seperate files.

And I have a few tips as to how to make it as natural sounding as possible. I didn't just record "Today is. Monday. November. Twenty. Third..." I recorded "Today is Sunday January 1st" and then "Today is Monday February 2nd" and then "Today is Tuesday March 3rd" and so on. I extracted the phrase "Today is..." from a sentence that had more words after it. I extracted "Monday" from a sentence that had words before and after monday. I extracted "January" from a sentence that had words before and after it. The engine, like humans, pronounce words differently if it is part of a full sentence instead of just reading the word. To further illustrate this, play my recorded november.pcm file all by itself and it will sound weird, without conclusion, as if it didn't finish its breath and is expecting to say more. But I didn't do this for the numbers so you can record "One. Two. Three..." without making it part of a full sentence.

Since this program is just a collection of 72 prerecorded audio files, it is certainly possible for someone to record their own voice instead of the computer synthesized voice. That would sound so much better then any TTS voice could and I think it would be real cool if someone did that.

BTW, I posted r5 of the TTS Clock at www.zabaware.com/empeg and I mentioned it on the general forum instead now as I think all the bugs have been removed and I included an automatic ftp installation script.

In reply to:

---

However, reading from config.ini to set TZ in the environment for other programs is probably reasonable for add-on programs, unless we can discover where the player stores its setting.

That last sentence is a challenge to someone, I hope.

---

Well, I don't know why nobody's suggested it yet, but there already is a timezone setting in the config.ini, at least for some people. When Mark Lord added a clock display to Hijack, he had the same problems not being able to get the timezone. So, he simply added an entry to config.ini where you could define the timezone.

The entry is:

[hijack]

time_offset=xxx

where xxx is the number of minutes positive or negative of UTC.

For example, mine reads

time_offset=-420

for Mountain Standard Time.


For Domo Kun's program, he should just scan config.ini for that setting, and use it when present.

But this wouldn't take account of DST.

Setting TZ and TZDIR appropriately in the shell script works.