No, firmly planted inside the state.

I've tried to switch between screens, but it just kind of locks when it gets to the map screen (although it displays a map) and the hard disks spin continuosly. If I toggle roadmap off and switch to the street, city display, the screen still says Unknown.

One time out of 10 tries (reboots), the City, State, County, Street, etc displayed and updated properly.

The time it did work, I was playing around with the preferences file, replacing the ' with the " on the new lines to add.

But since then, I've switched it back and forth with no luck.

Also, the tts doesn't seem to be working from within roadmapgpsapp, but I can telnet in and issue a "tts "hello world"" and it works (even though the volume gets whacked, I know what you mean by hearing loss now). Also, a ps -A shows that ttsd and flite are running.

Here's what my prefs file looks like:

Time.Zone: -8
Voice.Approach: tts 'Approaching %N'
Voice.Current Street: tts 'On %N'
Voice.Next Intersection: tts 'Next Intersection: %N'

Any ideas?

I actually had a similar problem when I was working on tts.. it appeared that ttsd slowed everything down so much that the Empeg became unusable. Then I tried again, this time I actually got in the car and drove around and the tts stuff worked without any apparent ill effects.
A couple things to try:
1. If you disable the tts stuff temporairly by making "tts" not executable (chmod -x tts) does Roadmap start working again?
2. Are you hooking up to an actual NMEA GPS or a simulator? I'm wondering if the position updates are coming so fast from a simulator (or fast updating GPS) that it's getting bogged down.
3. Are you testing in AC or DC mode? I don't know why that would matter as long as everything is getting started but it may be affecting the serial port somehow.

but it sounds like what we want.

Nein.. that's the rub. audio_overlay_bg_volume does, indeed, come from config.ini. But it's the volume of the MUSIC, not the PCM samples being written to the overlay buffer (from flite, in this case.) If I'm understanding your request correctly (and please tell me if I'm not) your claim is the TTS voices are too loud, and the music is "just as loud" until the speech is complete. Well I couldn't explain why the music was so loud, since the default for audio_overlay_bg_min is 0x00004000, but I don't know whether that number is relative to the player's existing volume, or absolute. So I suggested you take a look at tweaking the bg_min and bg_max values, which govern the range in which the audio_overlay_bg_volume (register 1 above) fades between when the overlay buffer is in use.

So in the assembly code above, the lines commented with "scale destination sample down by fixed-point multiplier" are using the value of audio_overlay_bg_volume to make the music quieter. What is absent from the above code is something that scales the contents of pSrcSample (r4) by some other factor. I had tried to hack something in quick to do it based on what's being done with the bg music, but what I tried wasn't working, and I didn't fully understand each step of the scaling code enough to debug it.

No luck finding a volume option in flite, either?

>>1. If you disable the tts stuff temporairly by making "tts" not executable (chmod -x tts) does Roadmap start working again?<<

Yes it seems to work better, roadmap is responsive and the city, state, street page is updated regularly.

>>2. Are you hooking up to an actual NMEA GPS or a simulator? I'm wondering if the position updates are coming so fast from a simulator (or fast updating GPS) that it's getting bogged down<<

Actual NMEA GPS. I think its updating 1 time per second... wonder if this is too fast? Hasn't been a problem in the past...

>>3. Are you testing in AC or DC mode?<<

DC mode in the car. I have a route loaded and if I disable roadmap, the route works just like it does with regular gpsapp. Also the position updates, spedometer, altitude, etc. work properly.

No, NMEA updates at once per second should be fine. I tried this out again and I'm pretty certain flite is just too slow. One of the reasons may be because it was apparently statically linked with another version of libc (thus making it 5 MB). Try running with the music paused- for me at least the voice does work but even then GPSApp is slow updating and gets behind in the queue of what it should say next. I'm going to try to recompile flite with the empeg's version of libc and see what happens next.

Ok just had another revelation though I haven't got a chance to test it yet. All we need for "tts" is a script like this:
flite -t $1 stdout

This should call flite with a specifically set text string and output straight to the Empeg's audio (because of the code changes ttsd's creator did to flite). Then we can get rid of ttsd altogether.. ttsd is basically a shell script that sleeps for a second and calls flite over and over- thus it introduces a big delay outputting speech and a big performance hit calling flite over and over again. If we can get this direct calling method to work the empeg just might have enough cpu to do this...

Ok I just drove around and pretty well confirmed that this works as a tts script:
flite -t "$1" stdout
I know this because I had:
flite -t $1 stdout
and was getting "Approaching" "On" (no street name) so the quotes should make it work. It seemed to working quite a bit faster too so we'll see.

Cool! I tried the same and it seems to work better now. FYI: I also took out my backup brand new player with no songs and a fresh processor, it seems to run pretty quick! Definately a handy feature! I think that the street names feature could really be useful in some situations!

Uh. You may want to change it to flite -t "$*" stdout
$1 will only give you the first argument

I guess that works better- I was going under the assumption that you would call the script with one argument in quotes like this:
tts "Approaching yourstreet".

Ahh okay. I've got a slightly different configuration so $* would be the right thing to do.

I've been away from the boards for several months and not worked at all on ttsd for about a year so I'm trying to play catch-up now...

IIRC, there's an option to flite "-l" that will cause it to sit in an infinite loop. I'm not sure if it will work as is with ttsd 1.0a3 or not, but if it does, it would be much better than the current shell script. Ideally, you'd be able to use hijack to launch a command like:

flite -l /usr/local/ttsd stdout

and not have the shell script at all... this would reduce the memory footprint (no bash) and decrease the delay time needed to start flite.

I finally got around to setting up my own web server so I'm not limited to 10M of web space. I've put all three releases on line now: ttsd-1.0a1, ttsd-1.0a2, ttsd-1.0a3.

If memory is still an issue, flite does have an 8KHz sample rate option (as was used in 1.0a1) and if you've got the time recompiling 1.0a3 using 8KHz samples would give a 4MB binary as opposed to the 5.9MB binary that uses 16KHz samples.

I'd be glad to answer questions if I can: amigo@theamigo.net