Just finished up merging GpsApp with a newer version of Roadmap and also adding a fun new feature. There is now a an additional info screen in RoadmapGpsApp that will tell you your current City,State,County and Address Block and also the Sunrise and Sunset time for your area. I for one am excited about the Address block display, it should be much better than squinting at buildings looking for numbers.

The install instructions have changed because of some differences with the new version of RoadMap. Mainly it requires you to make a symbolic link from /usr/share/roadmap to /drive0/roadmap where you installed all the roadmap files. This way you can throw all your Roadmap files in one directory.
Also, since apparently the Empeg does not define the Timezone in any known place you have to put your GMT timezone offset in the preferences file for the Sunrise/sunset calculation to be right.

Download it here

One other note: The new version of Roadmap supports voice announcements when you approach intersections, if you put flite in your /bin directory it should thereotically play them. Unfortunately the flite binary that was linked on this board seems to be gone, anyone know where to find one?

I don't think flite on its own will be of much use to you, for the following reasons:

1) In order to play speech while the player is running, you need a flite binary that takes advantage of Hijack's sound overlay functionality.
2) The empeg's sound device only accepts 44 kHz samples, and flite doesn't give you that kind of quality. So you need some sample rate conversion of the sound before it goes to the sound device.

Lucky for you, this problem has been tackled before, partly by myself, but mostly by Josh Harding, who released ttsd. It includes a flite binary that takes care of these two problems. It also allows you to create a device that you can just echo text to and have it spoken by flite. There's a bit of a delay, and flite's memory footprint is a little harsh, but it worked adequately for me when I was playing around with it a while ago. This is probably your best bet for seeing if the roadmap announcements work.

Josh doesn't frequent the BBS much (at all?) anymore, and as far as I know gave up on ttsd... But if you can't get things working, I should be able to help out.

Thanks for the info on that, I'll have to try that ttsd package out. Though I'm not optimitisic that with Roadmapgpsapp, the player and flite running their will be enough memory left to be useful. Anyone know if it's a goode idea to turn my /programs0 partition (which I don't use anymore) into a swap partition? I know it's possible I just don't know if it's a good idea or not.

Anyone tried it yet and have screen cap's of the new features?

There is now a an additional info screen in RoadmapGpsApp that will tell you your current City,State,County and Address Block

That rocks! Aside from true routing, address info is probably the most useful feature that could be added to gpsapp.

-Mike

I had the empeg hooked up a serial port so here ya go.

Does the sun really set there at 3:52 PM?

I was shocked at how early it went down the week I was in San Diego, and if you think about how time zone boundaries have been gerrymandered it makes sense. They should be every 15 degrees.

No I'm not that far north I was testing the timezone offset in the preferences file so I set it to -7 when it really should be -6. Just checked wunderground.com and the sun really does set at 4:51 PM so my calculation is still right- just the timezone is off.

>>One other note: The new version of Roadmap supports voice announcements when you approach intersections, if you put flite in your /bin directory it should thereotically play them. Unfortunately the flite binary that was linked on this board seems to be gone, anyone know where to find one?<<

>>Lucky for you, this problem has been tackled before, partly by myself, but mostly by Josh Harding, who released ttsd. It includes a flite binary that takes care of these two problems. It also allows you to create a device that you can just echo text to and have it spoken by flite. There's a bit of a delay, and flite's memory footprint is a little harsh, but it worked adequately for me when I was playing around with it a while ago. This is probably your best bet for seeing if the roadmap announcements work.<<

Anyone get ttsd to work with the voice announcements when you approach intersections? This would be the coolest feature IMHO!

-lothar

Ahhhh... perrmanent hearing loss. Well I got ttsd to work with Roadmap.. problem is I think the audio overlay code is screwed up on v3 alpha because when it did work it was so ungodly loud that I thought my ears were going to explode! I didn't know my cheap amp and factory speakers could get so loud. Anyways if someone wants to get hearing loss too, or possibly try this on v2 of the player here's the general steps:
1. Install ttsd, I suggest against using the M10ttsd preinit stuff though, just add a line like this to your config.ini instead:
;@DC ;@EXEC_ONCE /bin/sh -c "/bin/ttsd &" (assuming you install ttsd in /bin). I would also suggest making a link from /bin/flite to /drive0/flite since it's a 5 meg binary. Don't forget to set flite, ttsd and sleep executable.
2. Make a script that Roadmap can call- called tts with these contents:
echo $1 > /usr/local/ttsd
put this one-line script in your /bin directory and mark it executable
3. Now add these lines to your preferences file in your Roadmap directory:
Voice.Approach: tts 'Approaching %N'
Voice.Current Street: tts 'On %N'
Voice.Next Intersection: tts 'Next Intersection: %N'

As far as useful of the voice announcements go- they could actually be useful in some cases. I will definetly have to add an option to turn them on and off in the next release though.

I don't think it has anything to do with v3. The audio overlay code is all in the kernel and all it does is fade the music down and mix it with the PCM sound (coming from flite in this case.) Because the flite sound is at full volume and the music's faded down, it's going to be comparatively louder than the music.

If flite has an option for changing the volume of the voice, that might be a good thing to try. I can't remember if the player's volume knob also brings down the volume of the audio overlay samples, if not, maybe someone has to work on a more robust way to do the audio overlay stuff. I did at one time attempt to play with the sample mixing code to scale down the PCM sound by a configurable amount, but I have no ARM assembly experience so my feeble attempts came up short.

Hmmm, the audio was very loud compared to the music but the other problem was it would make the music just as loud as the audio until flite was done "saying" what needed to be said. So I wonder if their wasn't something else going on. I'll look into making the volume for flite softer. It would be even better of course if we could make the flite volume dependent on the players volume level- if we can figure out what the volume currently is somehow.

So I wonder if their wasn't something else going on.

Try adding settings "overlay_bg_min" and "overlay_bg_max" to your config.ini under the [hijack] section. The default values are:

overlay_bg_min = 0x00004000;
overlay_bg_max = 0x00010000;

I'm not certain, but reducing these values may help decrease the volume of the music as compared to the voice. I remember it working at one time, anyway. As to the voice itself being too loud, not sure there's a solution for that yet. My memory is fuzzy on this, but I seem to remember the number should be specified without the leading 0x (so maybe try overlay_bg_min=2000 and overlay_bg_max=4000 or something like that.)

if we could make the flite volume dependent on the players volume level- if we can figure out what the volume currently is somehow.

I think this would be pretty easy for someone (probably genixia) to do for you. He did the volume boost code awhile back and I think that requires some knowledge of the player's volume setting. If so, it's just a matter of exposing that value as an ioctl() that (our hacked version of) flite could call.

Ok... I followed all of the extended install instructions to get ttsd working.

Running 2.0 and here's what I get on the console after boot:

Hijack: intercepting config.ini

': not a valid identifieropts: `Option
Saved AC volume was 78
Volume=78
hijack_exec("/drive0/var/ttsclock -t-8"), rc=0 (okay)
hijack_exec("/bin/sh -c "/bin/ttsd &""), rc=0 (okay)
hijack_exec("/drive0/roadmap/roadmapgpsapp"), rc=0 (okay)
hijack: removed menu entry: "Hard Disk Detection"
hijack: removed menu entry: "Serial Port Assignment"
khttpd: listening on port 80
kftpd: listening on port 21
** roadmap_file.c, line 70: cannot open file //.roadmap/trips/default

Any ideas what these mean?

': not a valid identifieropts: `Option
** roadmap_file.c, line 70: cannot open file //.roadmap/trips/default


-lothar

Did you make the one line "tts" script as described? If you did test out your "tts" script by issuing a: tts "hello world"
on the command line to make sure it's working (i.e. you should hear it play). Also make sure you edited the roadmap preferences file and added the appropraite lines.
If all else fails you might try watching the console when GPS data is coming through- to do this you will need to run RoadmapGPSApp in a telnet session and maybe use a GPS simulator like NMEATool. This way you will see the Error messages that Roadmap returns when it can't run the configured tts binary.

BTW- the Roadmap trip error is normal, it happens because the Empeg doesn't have a writable hard drive.

Ok, I must be getting something wrong. Hello world isn't working...

empeg:/bin# tts "hello world"
/bin/tts: /usr/local/ttsd: Read-only file system
empeg:/bin# cat tts
echo $1 > /usr/local/ttsd
empeg:/bin# ls /usr/local
ttsd
empeg:/bin#

Also, upon bootup ttsd is outputting (speaking) the following over and over...

hash/bin/bash
hash if during install you place the fifo in different location edit the hash line below
/usr/local/ttsd is the default location

...

Looks like you didn't make the fifo or it didn't get created correctly. I had problems here too I think. To make the fifo:
Mount your drives read-write by issuing a "rwm" and a "rw". Then issue a "mkfifo /usr/local/ttsd". If this doesn't work you may have to do a "mkdir /usr/local" first as I did not have a /usr/local directory I think (also do a "ro" to remount read-only!). Do this and then restart ttsd and see what happens.

Don't do this anymore. Reinstall!

For some reason the FIFO wasn't created properly and you've got a text file in there instead.
Do this:

rw
rm -f /usr/local/ttsd
mkfifo /usr/local/ttsd
ro

Actually, (without knowing much about this whole process), it sounds like his ttsd binary is at /usr/local/ttsd. Removing it would likely stop it working at all. He probably needs to move /usr/local/ttsd to /usr/local/bin/ttsd, modify his startup to accomodate that move, then create the fifo.

But I could be totally wrong, as his startup seems to be referencing /bin/ttsd.

Yeah. Good point. Maybe it would be a better bet to reinstall it totally

Thanks for the tip. (oops, I guess there was an install script there)... )

Reinstalling it got me a little farther.

Now, at the shell, I can execute:

/bin/sh -c "/usr/local/bin/ttsd &"

Then I can type:

/bin/tts "Hello World"

and that works.

However, when the player is booting up, here is what it looks like (sleep and flite repeating forever):

Hijack: intercepting config.ini

': not a valid identifieropts: `Option
Saved AC volume was 78
Volume=78
hijack_exec("/drive0/var/ttsclock -t-8"), rc=0 (okay)
hijack_exec("/bin/sh -c "/usr/local/bin/ttsd &""), rc=0 (okay)
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
hijack_exec("/drive0/roadmap/roadmapgpsapp"), rc=0 (okay)
hijack: removed menu entry: "Hard Disk Detection"
hijack: removed menu entry: "Serial Port Assignment"
khttpd: listening on port 80
kftpd: listening on port 21
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
** roadmap_file.c, line 70: cannot open file //.roadmap/trips/default
Roadmap initialized
GPS app started
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
player.cpp : 385:empeg-car 2.00 2003/04/01.
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found
/usr/local/bin/ttsd: sleep: command not found
/usr/local/bin/ttsd: flite: command not found

That's bizzare- I'm not sure how tts is working if you getting those messages. In any case you just need to put flite and sleep somewhere in your path- I put mine in /bin, although I guess /usr/local/bin is the "right" place. Note: I would suggest making a symbolic link to flite and put flite somewhere on your /drive0 since it's so large. (i.e. ln -s /drive0/roadmap/flite flite)

Cool thanks.

No longer getting the error messages on the console... I'll test it out and report back.

One last thing - the city, street, state, ... screen displays the following:
City: Unknown
Street: Unknown
State: Unknown
County: Unknown
Rise/Set: 7:51 17:50

Also roadmap overlay is working fine, so the maps are correctly loaded!

TIA

That's bizarre. Have you tried changing back from the map screen and then back to the address screen once or twice? It should at a minimum find a county unless you are in a location where you don't have a map. You haven't "drifted" into another state by any chance have you?
If you can't get it to work send me the GPS Position you see on the satelittle display and let me know what state you should be in and I'll try to reproduce it.

On another note, did you get a chance to try those config.ini settings to see if they help out with the loudness of the music in relation to the ttsd output? If it's really a problem and we need to scale down the ttsd samples, we'll have to find someone on the board who's comfortable tweaking the ARM assembly code that does that dirty work. None of the obvious tweaks I tried seemed to work. Any takers?

__asm__ (

    "stmfd  r13!, {r0-r12,r14}\n\t"



    // initialize registers

    "ldr  r1, %0\n\t"       // r1 = audio_overlay_bg_volume

    "ldr  r4, %1\n\t"       // r4 = pDstSample

    "ldr  r5, %2\n\t"       // r5 = pSrcSample

    "mov  r6, #2304\n\t"      // r6 = loop counter

    "sub  r6, r6, #1\n\t"     // r6 -= 1

    "mov  r7, #65280\n\t"     // r7 = ...

    "add  r7, r7, #255\n\t"   // r7 = 0xFFFF

    "mov  r8, #32512\n\t"     // r8 = ...

    "add  r8, r8, #255\n\t"   // r8 = 32767



    ".MixLoopStart:\n\t"



    // scale destination sample down by fixed-point multiplier

    "ldrsh  r0, [r4]\n\t"     // r0 = *pDstSample

    "mov  r0, r0, lsl#16\n\t"   // r0 <<= 16

    "smull  r2, r3, r1, r0\n\t"   // r2 = lo(r1 * r0), r3 = hi(r1 * r0)

    "adc  r2, r2, #32768\n\t"   // r2 += 32768 + carry

    "mov  r2, r2, lsr#16\n\t"   // r2 >>= 16

    "and  r3, r3, r7\n\t"     // r3 &= r7

    "orr  r0, r2, r3, lsl#16\n\t" // r0 = r2 | (r3 << 16)



    // add source sample to scaled destination sample

    "ldrsh  r2, [r5]\n\t"     // r2 = *pSrcSample

    "add  r2, r2, r0, asr#16\n\t" // r2 += (r0 >> 16)

    // clamp destination sample up

    "cmp  r2, r8\n\t"       // if( r2 > 32767 )

    "movgt  r2, r8\n\t"       //     r2 = 32767



    // clamp destination sample down

    "cmn  r2, r8\n\t"       // if( r2 < -32768 )

    "mvnlt  r2, r8\n\t"       //     r2 = -32768



    // put processed sample back to memory

    "strh r2, [r4]\n\t"     // *pDstSample = r2



    "add  r4, r4, #2\n\t"     // r4 += 2 (get next dst sample pointer)

    "add  r5, r5, #2\n\t"     // r5 += 2 (get next src sample pointer)



    // loop back

    "subs r6, r6, #1\n\t"     // r6 -= 1

    "bpl  .MixLoopStart\n\t"



    "ldmfd  r13!, {r0-r12,r14}\n\t"

    : // no outputs

    : "m" (audio_overlay_bg_volume), "m" (pDstSample), "m" (pSrcSample) );

}

.

I haven't tried the config.ini settings yet. I'll try to do that tonight. Well I must say ARM assembly looks pretty close to x86 assembly so it might not be so bad to deal with. Although if this code is in the kernel I really don't have a development environment setup to compile it- Cygwin just won't cross-compile a linux kernel.

Although if this code is in the kernel I really don't have a development environment setup to compile it- Cygwin just won't cross-compile a linux kernel.

Not a problem, I can compile it just fine. I just wasn't able to get the volume-scaling of the PCM overlay to work right, though I only spent about 20 minutes on it at the time. I was probably making it more complicated than it needs to be, but assembly's never been my strong suit.

Edit: BTW here's an ARM instruction set cheat sheet that might be helpful.

Excellent; My AFS port needs some minor assembly that I was unable to do, I suspect that will help.

hmm, first step in analysis seems to be to find out where the input "audio_overlay_bg_volume" comes from. I'm guessing that may come from or be affected by the config.ini settings.. but it sounds like what we want.

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: [email protected]