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.