Hi.

As many of you know, I have been trying to start this project for quite some time now. I hoped to cooperate with Kim Salo, because he already has large parts of a navigation system going, but he is either too busy with other projects or is simply not wanting to let others in on his project. At least I was unable to get any information from him for quite some time now, and I couldn't find a web page with information on his current project state either. Seems like we have to re-invent the wheel on this.

Anyhow, I just collected a few tasks that need to be completed to get a navigation system running (well) on the empeg. I listed them below, some are very detailed, some less detailed, some are huge tasks that probably need more than one person to fulfil them, some are minor tasks that might get done within a few days. Here is the list:

1. Software installer for the empeg, to make software installation easy for end users. This should be relatively easy to do using the info at the tweaking/programming pages at http://www.incase.de/framed/empeg/


2. Sound-API/Display-API/UI-API this might be a bit more time consuming, but should be farely easy to do, just needs some write-up. This will be needed to draw a neat line between the interfacing parts of the program and the actual logic in it


3. serial access to GPS (and other sensors, see below), ideally, this is goint to be neatly encapsulated, too. I really want the core of the system to be as independ of the hardware and operating system as possible. This will make porting to other architectures easier and might even attract people from outside the empeg scene.


4. MAPS we need maps for the various areas we are going to cover. For europe, I would recommend the maps provided by AND (http://www.and.com/), but they are expensive as far as I know. I would really appreciate help in this area. I currently don't have the time to do intense internet research for map data (and even more important: The data format specs for that maps). So if anyone would contact the various providers of map data and find out their conditions, this would be great.


5. A small serially connected device would be great that allowed the parallel use of a GPS and some other sensors (like compass, speedometer etc.). Most commercially available systems only use GPS for their initialization and use compass and speedometer sensors mainly to keep track of the current position, because GPS is not always available within a city.


6. A program framework that links the user interface with the real functions of the system.


7. A converter that converts the various map data formats to one format that we will use internally (well, the internal data format also needs to be specified here)


8. Many, many, many functions that build the real core of the system, like the position estimator (that reads the GPS, compass and speedometer information as well as the map data and estimates the current position, direction and speed), the advisor (that tells the driver where to go next) and the innermost function: The routing functions that calculate the route the driver should go.


9. Even more functions that are linked to the UI, like setting up the type of car, the drivers preferences (likes to use freeways or "normal" streets, likes to drive relatively slow or fast) etc....

In other words: There is a whole lot to do, and I really would like to get this going. This project will probably involve many different activities, contacts to the industry (map data, GPS receivers,...), hardware design (interface for speedometer+GPS,...) and last but certainly not least the software development itself. If we want this to grow to a usable system fast (within a year or two), I would say that we need at least 5 or 6 active people (putting in a lot more than just a few hours of work each month): One to acquire the information needed (map data and associated data formats, licensing information for the map data etc.), one for the hardware job (GPS+sensor interface) and 3 or 4 people that actively develop the software. note that this software development should be general enough to be of use to other projects (even non-empeg ones), too. The innermost core, the navigation/routing itself could best be handled by one or two developers, I guess.

Ok, anyone that would like to help with personal effort, please contact me via email (sven-navem@incase.de), stating your skills and your estimate on how much time you would be willing to invest on this project. Anyone that can not help in person, but still wants to help, here are a few things that would help me getting the project started a little bit faster than I would expect it to start currently:

• a notebook harddisc for my empeg, anything with at least 4gb would help. My empeg is simply full to its limit currently, and I don't have much money at the moment, so I can't buy one


• a GPS receiver that has a serial port and is capable of talking NMEA


• a serial cable (to connect it to the empeg) and power supply for the GPS receiver


• Oreos


• A bottle of really good whiskey

I anyone from Europe would be interested in helping on the software side, I would like to arrange a meeting on some weekend in late october / early november, to discuss the primary program layout and such things. I can provide sleeping space for up to four people (two for each room).

Geee, I just realized that I didn't work on the project for almost a year now, due to my studies, work and personal things. I really need somebody else involved with this project to gently kick my lazy ass from time to time ;-)

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

As there has been discussion about my navigation project also in other threads, I thought that it is most informative to gather a small Q&A list to get most of the questions answered.

Q: Is the navigation project still going?
A: Yes, it's still alive. It has been more or less work-in-progress since March 2000 when I had the first empeg vs. GPS communication running on my Mk1.

However, for the past half a year, not much has happened since I've been extremely busy with my primary work. Fortunately, things are getting balanced and I hope to spend more time with the navigation soon.


Q: Could you enlighten us on the current state of navigation software?
A: Essentially it's able to project the car's position to the vector map and show the current street name along with street numbers in realtime.

It has a preliminary route planning and guidance feature which lets you to type the destination street name either by using the remote or the rotary knob which after it calculates the shortest/fastest route and starts the guidance. The route planning takes turning restrictions and one-way streets into account.

It does not utilize any PDA device thru IrDA anymore as it turned up to be not so practical solution for in-car use. Instead, all feedback to the driver is given with speech prompts.

Big part of the design was to smoothly integrate the navigation with the existing player software. All speech prompts are mixed with the regular player audio output and therefore the music is faded down to 50% of its normal volume while the navigation speaks the guidance and other information on top.

The display shows the current street name, information about the route such as estimated arrival time/distance left to the destination. It can also show extended GPS information such as speed, number of visible satellites, etc. The navigation software is controlled with the front panel buttons and remote with certain keys fixed to change the focus between the player and navigation software to allow better control. While the navigation software has focus, it has internal menus where various things can be controlled -- meanwhile the player continues to play music on background and remains unaccessible until focus is switched back.

As noticed, there's no web site for the project as I don't see it too useful to hype something that is not publicly available yet (excluding the reference on geek site).


Q: Will it ever be available to general public?
A: That mostly depends if the project gets into a state where it's useful for other people. To make it work with other environments, it will require things like proper installation system (as it requires kernel modifications, relies on having a custom scratch mount point, etc).

The biggest obstacle however being the maps and the interface between the program and various map formats (and each geographical area needing a specific map projection code). Once the map interface works better and has support for other map types, it will be much closer to a state where other people could potentially use it.


Q: Do you need help?
A: At the moment, I don't feel comfortable to turn the project into a massive team effort as I know that it will easily get out of hands without a proper coordination especially since the programming work is not the key fact slowing down the development. It would be different case if I would be starting the project now, but since it's been going on for the past 1,5 years there's a lot of ideas regarding the design/implementation and experiments that I've made which affect to the overall direction I see it going.

However, if at some point I feel like dropping the project, I don't see it as a problem to contribute the existing work to the community. On the other hand, once it's actually possible to use the software in other environment, I'm sure there are many aspects where testing in different countries and geographical areas would help.


Q: Will the source be available?
A: There's no definite yes or no. However, I see it more likely to have a binary version available sooner than the source. Future will indicate where the project goes and which option seems better.


Q: What map types are possible to integrate with it?
A: It's solely based on vector maps which represent the street network using some known map projection formula. However, to get it work with multiple data sets, it seems pretty essential to have the source data always in same format.

For now, it looks like the TeleAtlas maps will be the ones that I'll investigate further. Partially, because it is the only company producing street-level vector maps for Finland. They also have pretty good coverage on Europe and US.

Kim

Hi Kim.

This might be an exaggeration, but if I wanted to summarize your post into 3-4 sentences, I would do it like this:

1. The software seems to be pretty well usable for you and seems to have quite a few features I would like to see on such a navigation software.


2. The maps you currently use are available for Finland only, other maps use different projection methods and are therefore not compatible at the moment.


3. If some other people want to do a navigation software project, it is either in parallel with your project, or not happening at all (for now).


4. If your software ever reaches a state where you don't want to improve on it anymore, you will probably release it as open source.

Is this right? If so, it doesn't make me happy, but it is your software project, so it is your decision. In this case, I see no other option for me other than starting a seperate project for some other navigation software. However, I will probably investigate on the lower level sub-projects first (UI-API, Sound-API, Player/Navigator skeletton, Plugin-API,...). This might help your project as well, if you get it to a releasable version within the time we need to finish the basics. It would be great though, if you would help us with some information like the data format of the maps you use, NMEA communication routines etc.

cu,
sven

PS: Nice to read some news about your project anyway, I always wondered how you got along with it. I would really like to give it a try, too. If your software is even half as good as it sounds by now, it is better than what I had in mind as a primary public alpha version.

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

You're determined to make me regret getting a separate nav unit aren't you

Rob

This might be an exaggeration, but if I wanted to summarize your post into 3-4 sentences, I would do it like this...

Roughly, your summary was about right.

It would be great though, if you would help us with some information like the data format of the maps you use, NMEA communication routines etc.

Sure. If you get a project moving (will it be whatever), I'm happy to help if you are having problems with something that I've gone through or would have a clue otherwise. It would be nice to see more 3rd party projects and applications going on with empeg as so far they have been pretty limited to DisplayServer and Tony's logo editor plus some smaller helper tools.

Still, what goes for the map formats, the one that I currently use is based on raw MapInfo mid/mif files which are relatively easy ascii files to interpret. However, most of the other formats used by NavTech, TeleAtlas and other car manufacturers (Mercedes, VW, etc) are using their own proprietary binary format, for which they are not likely to release any specs.

I'm aware of the SDAL project which is supposed to fix the situation but as it's owned by NavTech, it automatically means that TeleAtlas (which is their direct competitor) is very likely not going to support nor use it. That kind of breaks the idea of having a one common file format for the maps. Perhaps, it should have been designed by an organization who has nothing to do with the existing companies working on the field to ensure that everybody is on the same line.

However, if somebody happens to have more information or specs on various vector map formats, feel free to let me know.

Kim

Hi Sven,

I would not be able to offer any help with the programming but I do have a VDO Dayton MS5000 nav system and an empeg. I also have all of the map CDs for Europe so as I only can use 1 at a time I can send the one I am least likely to use to you.

I would also be able to test the 2 systems side by side for comparison.

The VDO maps (I am not sure who provides the content) are available for Europe and the US so this would seem like a good place to start. They seem accurate and have street numbers etc. They are available from most GPS sales sites for around UKP80 each.

MK2 Red S/n 949

As far as the specs for SDAL go, unless I am mistaken I have their documentation for that. Mind you from the noises I hear NavTech is pretty much closing up shop in a couple of places. Holland for one seems to be going away. At any rate as I have stated before, and this is to both Sven and Kim, I have a couple of GPS receivers (a Garmin OEM module which is NMEA, and a Delorme Earthmate which uses a binary output format that is Delorme specific) and would be more then happy to help test or whatever. I would also be perfectly willing to donate (if that is the term) some resources to Sven and/or Kim (I think I can probably dig up 1 or 2 laptop drives for testing purposes, mind you mostly 2 gigs perhaps a 4 or a 6 gig if I get REALLY lucky).

Cheers,
Hans


Mk2 - Blue & Red - 080000431

I have found hazardly during search for Linux programs.

It has interesting features :

GpsDrive

Empeg II - 10 Gb - Red Fascia - 750 Songs -

- I Will Strike From the Grey -

But Rob, just think, I am so glad you did........ :)

-Steve

//== MK2 20 GB Single Drive, Green Face Plate Currently installed in Toyota Solara ==\\

This looks very promising. If I had enough programming savvy, I would probably start working off this since it looks pretty mature. Even as a GPS solution for my laptop this looks good.

EDIT: Maybe if a bunch of us got together and bought this guy an empeg he would work on the port. I'm in for $100.

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

Edited by robricc on 11/10/01 09:27 PM.

Hi.

Yes, that project sure looks promissing, but there are a few things I noted while studying the readme file. First, it currently only is a moving map display, though a very intelligent one. Great if you want to try and find your way in an unknown environment, bad if you want to get guided through an unknown environment. Second, it doesn't use street based maps/vector maps which makes it almost impossible to do real street to street navigation, there simply is no information about streets/street names in those maps.
That system is surely interesting and far more advanced than my software will be by the end of the year. It seems to be a dead end in regards to a street level navigation system / guidance system though. Don't get me wrong: This is an extremely good piece of software as it seems, just not the kind of navigation system I would like to use in the car. I would use it on a mobile computer though if I were walking through an unknown city, just like I used the great software StreetPlanner from Palmtop BV (Netherlands) on my Psion Series 5mxPro some month ago.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Good points. It keeps looking like the main snag is the maps.

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

While on the topic of vector maps, I recalled some software I saw a while back. This is for the palm. The maps are seperate files that claim to be vector drawn with street data and such. You can view the available maps without a password. There are many different countries. May be able to find out where this guy is getting the map data.

Quo Vadis

Just trying to help,

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

As someone else mentioned it sounds like good vector map data is the biggest thing lacking at this point. Do you think it would be worth starting off with regular maps to get something going until a vector map data source can be found? If someone can get a simple moving map display working it could draw a lot more attention/help to the project.

-Mike

maps are seperate files that claim to be vector drawn with street data

Did you read the legal stuff? The maps may be used on one computer (not a problem) inside your own building (at least that's what the jargon says for the European maps. Not good for a GPS system, is it ? But it'll keep the lawyers happy!

Henno
mk2 6 nr 6

What if you live in your car?

-Zeke

just say you weren't paying much attention...

There was an interesting article about Nav system maps in this months automobile club magazine here in Germany. They were mainly complaining that there are no standards for map data for navigation systems! There seem to be 2 main map providers - Tele Atlas (Belguim) and Navtech (USA) - but in spite of this you often can't share the map CDs with your friends as almost every Nav system manufacturer customises the information on the CD. However, If you are lucky enough to be using a Tele Atlas system from Siemens-VDO or Blaupunkt you *should* be able to swap CDs with your friends. There also seem to be a lot of vehicle manufacturers using one of these systems (15 listed in the magazine). There are also 5 more manufacturers delivering vehicles with a Navtech CDs and a Siemens-VDO Nav system that can also use the Tele Atlas CDs if you want. My suggestion: maybe we should look at something like the Tele Atlas map system as the CDs are likely to be more readily available. There are other aftermarket companies producing map CDs for these systems, and they are of course mainly producing CDs for the most used systems. This makes CDs for these systems likely to be a bit cheaper too. Well one can only hope!! What does everyone think?

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

Will it be possible to use a 'Proprietary Format' for Empeg :

With the Nav system on Empeg we could imagine a utility to convert maps to Empeg format and anyone could use aby map :

You put your Map CD in your PC , use the converter and then upload it to EMpeg .

Is it really possible or requires too much work ?

Empeg II - 10 Gb - Red Fascia - 750 Songs -

- I Will Strike From the Grey -

Will it be possible to use a 'Proprietary Format' for Empeg :

With the Nav system on Empeg we could imagine a utility to convert maps to Empeg format and anyone could use aby map :

You put your Map CD in your PC , use the converter and then upload it to EMpeg .

Is it really possible or requires too much work ?

That is actually the only possible way to go around the problem Derek was addressing with the incompatibility issue between different map vendors. A proprietary format is also necessary to get the data structures optimized in a way which fits best for the program.

The biggest bulk of work is to write 15 different converters to convert the data to the proprietary format. And you are pretty much forced to reverse engineer the data format used in the CDs as it will be very difficult to get any format specs. It's not likely that you can obtain format specs from TeleAtlas or NavTech for instance. I believe they are anything but open-source -- you might be able to get the specs by negotiating and signing pile of NDAs, though.

Then again, from the map vendor's perspective, they don't see this kind of project that interesting (commercially) as the amount of players (and potential customers for this kind of project) is relatively small, especially with the EOL announcement.

Kim

Anyone in Belgium want to have a go at talking to Tele Atlas anyway? Maybe if we could convince a couple of them to buy empegs ....

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

Hi.

If anyone could get the specs to the Tele Atlas maps, that would be exceptionally helpful. I am aware that they might want to charge quite some money for that and/or require to sign a NDA. I just hope they don't.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Hi.

Do you think it would be worth starting off with regular maps to get something going until a vector map data source can be found? If someone can get a simple moving map display working it could draw a lot more attention/help to the project.

In principle, this is a good idea. However a moving map display isn't really of much use on the empeg I guess. Remember that it only has a 128*32 pixel display.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

ROFL

___________
Tony Fabris

Anyone know if the maps at mapopolis.com are vector? The ones with street data are dirt cheap, and the ones without are just free.

RioCar (40Gig) Blue/Red/Green
'01 Audi A4 2.8 Quattro

However a moving map display isn't really of much use on the empeg I guess. Remember that it only has a 128*32 pixel display.

Excellent point. I just would love to see something actually get started. I have always thought some sort of nav system would be a great app for the empeg.

-Mike

This software seems it might be helpful. I try to download it, but I get rejected. The GPS communication portion is open source. Mayko map.

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

This looks good and free for US maps. No, I'm not just trying to up my post count.

Tiger 2000 Data

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

Kim, sorry to bring up an old post, but what are you using for your voice prompts? Are you just using pre-recorded PCM sound files, or are you using a text-to-speech engine? If so, which one? I am investigating text-to-speech products myself for my Trivia game and as a general purpose way to get the Empeg to speak (reading textual news/weather reports, etc.)

Kim uses PCM, which I believe has been generated offline by a rather nice TTS.

If you want to run TTS on the player, you might consider Flite (http://www.speech.cs.cmu.edu/flite/) which is rather more managable than Festival. The quality isn't bad for a free system - but not a patch on the commercial ones. It has been observed to run successfully on an ARM Linux platform not so dissimilar to the car player.

Rob

Yah, I have actually been in conversation with the Flite author recently. I compiled Flite last night and it does a good job of creating WAV files of the spoken text, but I can't get it to output sound because of the 4608 byte restriction on /dev/audio. Flite writes 256 bytes at a time. I'm going to try to hack around it, the author wasn't able to give me any help on that front, unfortunately.

I was just asking if Kim was using Flite or something else. If he had gotten Flite to output to /dev/audio, he would have solved one of my current problems and I would have begged to see what he did. :)

Interestingly enough the Flite package is being rolled into a commercial product. The author says that Flite will be back-filled with the innovations from the commercial product, but the voices won't be as good on Flite to encourage people to buy it. Whenever I hear this, I translate that into "the freeware/open-source product is now dead, forget about it." I am sure the Empeg will be an exception to that rule. :) But he says that Flite will get better voices and better part-of-speech recognition soon. Until that happens, I guess PCM is the way to go.

I was just asking if Kim was using Flite or something else. If he had gotten Flite to output to /dev/audio, he would have solved one of my current problems and I would have begged to see what he did. :)

As Rob said, I'm using offline created PCM samples, which are generated with AT&T Labs Natural Voices which is the best TTS I've ever heard and which can be freely used.

For the navigation system, it works fairly well. I mostly need numbers anyhow, and I can easily represent any decimal or floating-point number between 0 and 999 in high quality with a single 400KB WAV file. For other speech prompts I need to generate them manually one by one.

Kim

...the 4608 byte restriction on /dev/audio. Flite writes 256 bytes at a time.

dd obs=4608 ?

Peter

As Rob said, I'm using offline created PCM samples, which are generated with AT&T Labs Natural Voices which is the best TTS I've ever heard and which can be freely used.

It can be used freely nn times a day from their web site, but a single user desktop licence (with which the PCM output cannot be distributed) costs $49. More useful commercial licences are somewhat more expensive, but still excellent value for money considering the quality.

Rob

Yeah... even when I do

dd if=file.wav of=/dev/audio obs=4608

I don't get any sound at all. So I'm thinking it has something to do with the Sound Overlay kernel which is currently installed on my Empeg. I'm going to try to back that out and see if I am still getting silent sound output. I just remembered this morning that I had installed that kernel patch. Not sure if that's the problem..

Assuming the WAV file isn't silence, I should get sound output when I run that dd command, right? There's no ioctl's I have to call to change the volume or select PCM source, are there?

So I'm thinking it has something to do with the Sound Overlay kernel which is currently

If you open the /dev/audio without the O_SYNC flag, there is no difference in the way how the audio is outputted.

Assuming the WAV file isn't silence, I should get sound output when I run that dd command, right? There's no ioctl's I have to call to change the volume or select PCM source, are there?

There are multiple. And if you try this so that the player application is not running, it's likely that the soft audio mute is enabled.

After you've opened /dev/audio, try this:

int iMixer = open( "/dev/mixer", O_RDONLY );
int iSource = SOUND_MASK_PCM;
int iFlags = 0; // source not muted
int iSAM = 0; // SAM is off
int iVolume = 100 | (100 << 8);
ioctl( iMixer, _IOW( 'm', 0, int ), &iSource ); // set source
ioctl( iMixer, _IOW( 'm', 1, int ), &iFlags ); // set flags
ioctl( iMixer, _IOW( 'm', 15, int ), &iSAM ); // set Soft Audio Mute
ioctl( iMixer, MIXER_WRITE( SOUND_MIXER_VOLUME ), &iVolume );
close( iMixer );

Kim

Aaaaaaah I think it is that soft audio mute... I was confusing that with cell-phone mute which I don't have tied to anything... I didn't know that SAM was enabled when the player exits.

That's the problem. Thanks muchly.

What the hell is soft audio mute supposed to do anyway?

OK, so you knwo I would be posting on this given recent events.

L&H's website also has a free converter for test-to-speech with a female voice. IMHO, the AT&T Labs version sounds much better but at least you have another resource. I can't wait to get my hands on some of this technology to play with.

Greg

Okay Kim you seem to have a handle on this sound stuff... explain this to me. I can now hear output, but I can't set any of the parameters like are set in the pcmplay example... So 8 KHz wave files come out sounding like a record playing super fast. In order to get pcmplay to work, I have to comment out all of the mixer ioctl's which set the format, frequency, etc... Or I get something like this:

ioctl(SNDCTL_DSP_SETFMT): Invalid argument

Here's the section I had to comment out to get it to play anything:

format = AFMT_S16_LE;
if (ioctl(fd, SNDCTL_DSP_SETFMT, &format) == -1) {
perror("ioctl(SNDCTL_DSP_SETFMT)");
return -1;
}
if (format != AFMT_S16_LE) {
fprintf(stderr, "AFMT_S16_LE not available\n");
return -1;
}

stereo = 1;
if (ioctl(fd, SNDCTL_DSP_STEREO, &stereo) == -1) {
perror("ioctl(SNDCTL_DSP_STEREO)");
return -1;
}
if (!stereo) {
fprintf(stderr, "stereo selection failed\n");
return -1;
}

speed = 44100;
if (ioctl(fd, SNDCTL_DSP_SPEED, &speed) == -1) {
perror("ioctl(SNDCTL_DSP_SPEED)");
return -1;
}
if (speed != 44100) {
fprintf(stderr, "sample speed 44100 not available (closest %u)\n", speed);
return -1;
}

Any idea what could be happening here?

Okay Kim you seem to have a handle on this sound stuff... explain this to me. I can now hear output, but I can't set any of the parameters like are set in the pcmplay example...

The pcmplay example is obsolete...

So 8 KHz wave files come out sounding like a record playing super fast. In order to get pcmplay to work, I have to comment out all of the mixer ioctl's which set the format, frequency, etc...

The audio input is locked at 44KHz, 16-bit stereo, little-endian signed with buffer size of 4608 bytes (size of one mpeg frame). If the program only outputs PCM at 8KHz, you need to manually convert it into 44KHz .

Kim

The audio input is locked at 44KHz, 16-bit stereo, little-endian signed with buffer size of 4608 bytes (size of one mpeg frame).

Doh! Is that new or has it always been that way? The pcmplay example would have one believe you can select mono/stereo, 11/22/44 KHz, etc... I knew the size of the buffer was locked...

This is a bit disappointing to my plans to get text-to-speech on the player. Sigh.

So, continuing the thoughts in my last post...

If it's indeed impossible to change sample rates, etc... Would it be possible to make some kernel modifications to enable the playing of formats other than 16-bit 44.1khz stereo? I mean this is REALLY limiting for a product whose primary purpose is as an audio player! I know this locking was chosen to keep the visuals in sync with the audio, but is that saying that there are no ways to keep the visuals in sync and still be able to accept other formats?

That sounds more like a DSP limitation than a kernel limitation to me. Mind you, I know nothing about this stuff, it's just an observation off the top of my head. If that's true, then any translation/resampling work would have to be done in software.

Yeah it appears there's no way to play anything other than 44.1 khz stereo. Sigh. So I have to figure out a way to do some conversion. I have zero experience in this. Anyone have any idea how one would "upsample" an 8000 or 11000 khz mono wave to 44.1 khz stereo? After about a half an hour of looking I couldn't find any way in the flite code to output at 44.1 or stereo. So I'd have to take its output and upsample it before it writes it... I just have no clue how this would be done. This is bound to be very inefficient. CRAP. I am so angry about this limitation, even though I know why it's there I wish there was like a second audio device that didn't have such stringent requirements.

The comments in empeg_audio3.c state "wishlist: sample rate adjustment with antialiasing filters." If this would allow us to write non-standard sample rate files to the audio device, then I hope this wish comes true. Hugo, are you listening? Or maybe there are some other smart people out there who could handle something like this, since the likelihood of this becoming an official feature is rather slim. Sigh.

That's the rate supported by the hardware. If it isn't convenient you can resample in software - it's not such a great programming challenge really (i.e. I'm sure someone on here knows how to do it - we had to!).

Rob

Check here..

http://www-ccrma.stanford.edu/~jos/resample/

Thanks for the link, Rob. Now, does anyone have any pointers on how to convert from mono to stereo? I want to do sample rate conversion and mono->stereo conversion in real-time so I'll have to graft this resampling code in, but I also need something to switch it to stereo.. any ideas?

A question for Smu :

Will you consider localization in audio sounds or just let english sounds ?

Now, does anyone have any pointers on how to convert from mono to stereo?

Erm... Just output the same sample twice .

Each sample is one 16-bit integer for one channel. For stereo, just output the same 16-bit integer twice in a row (for left and right channel).

For the sample rate conversion, from 11KHz to 22KHz or 44KHz is very easy as you only need to output the same sample either two or four times, as they are multiples. 8KHz is more difficulty as you'd need to filter it upwards, thus more expensive.

For instance, converting 11KHz mono sound to 44KHz stereo sound, you just output the same sample 8 times (x 4 for sample rate conversion x 2 for stereo).

Kim

Thanks for the excellent information, Kim. I figured stereo would be something like that, but I wasn't sure if it was a block of left samples followed by a block of right samples, or whether channels alternated on each sample. Thanks for the clarification.

The Flite software only comes with an 8 Khz voice right now. Future versions might have 11khz voices. I am going to try to mix in some of the upsampling code that Rob pointed me to and then try to hack in the mono-stereo conversion on my own. After all of that work, I can only pray that it performs fast enough to allow for somewhat real-time text-to-speech. Hey, I've been wanting to dig into a more low-level project on the Empeg, so this isn't totally a bad thing. Should be fun.

Don't forget to include a hidden option for taunts and other insults. That way you can trigger them from the remote without having them visible on the screen. Passengers will get a kick out of it. :)

Bruno

Hi.

I don't intend to do the sound output stuff myself (yet), so this wil depend on co-developers. Anyhow, my nav project is advancing _really_ slow currently, my diploma thesis is top priority for me.
However, I would like the software to have at least english and german speak output. No streetnames though, if there is no realtime TTS software that is completely free (BSD style license or something like that).

cu,
sven

Sven,
It might be a good idea to incorporate some IVR (Interactive Voice Response) tactics in the design of your Nav. Mainly, allowing the user to record his/her own prompts. This works for the majority of your grammar (North, South, 10 Miles, etc), and allows for dynamic data like street names. We've been doing this in the IVR industry for decades. If you want, email me off-list and I can give you some ideas.
Jason

Along with that little red button under the gear shift knob?

Hi Jason.

My plans go in that direction, but as of now, I am too far away from that stage of development to actually think about the deeper program structures. But I promise to keep all that in mind.

cu,
sven

The existing Linux/unix "sox" program is excellent for performing rate/channel/format conversions to/from just about any sound file format.

"Sound eXchange : universal sound sample translator"

Oh.... maybe I'll steal some of the code from there instead of rolling my own. It looks like SoX is made for converting *files*, whereas I really want to convert the samples as they're generated by the text-to-speech program. I guess I can find the relevant pieces of code and hammer them into the TTS software's source somewhere.

Certainly not as elementary as a /dev/audio that accepts other sample rates, but certainly doable.

Sox will work in a pipe as well, but the buffering may or may not match your needs.

Ah... I will toy with it this weekend probably, then.

Kinda thinking aloud here:

44100 / 8000 is almost 5.5.
8000 * 5.5 = 44000
Close enough that the playback speed would be off by 0.23%. Prolly not enough to make a difference for TTS.

Off hand, I don't know how to do the half in there. If you read in pairs of samples and output 11 at a time, how do you do it?
A: input = (-14, 120) output = (-14, -14, -14, -14, -14, -14, 120, 120, 120, 120, 120)
B: input = (-14, 120) output = (-14, -14, -14, -14, -14, 53, 120, 120, 120, 120, 120)
C: none of the above... something better.

At least A and B would be pretty easy to program and not very CPU intensive.

Smu,

Is the navigation project going well? If you guys would like, I can contribute to the project in the way of maps. I have several contacts over at NavTech. While a deal directly with NavTech is not likely to be struck, there are backchannels and other methods for obtaining the license cheaply.

If there is already a source for the maps, then I'll let this slide.

Let me know.

Calvin

This would be fantastic! Kim and SMU have been looking for that for a while. I think the maps issue is the main hold up.

Maybe PM them both?
G

This would be fantastic!

I'll second that. The maps seem to be the biggest holdup for any GPS project at this point. Calvin, if you have connections, please use them!

-Mike

So, Calvin, why didn't you pipe up a long time ago?

Hi.

For the software side of the project: Don't ask me, Kim is so much more advanced with his software, that I dropped my own development branch almost completely (i.e. everything that can't be used for other projects).

As for the map source: That is still our biggest problem, so any help is appreciated a lot. Please try whatever you can to provide us with maps and the necessary license(s).

cu,
sven

As of an update to the map situation, after spending lot of time investigating with the USGS vector maps, I can't figure out the direction of one-way roads. Also, there's the additional problem of merging the Tiger and USGS maps together with the position inaccuracies.

However, I've recently found one possible source of map data which is designed for car navigation and the maps are available for both US and Europe. But I need to investigate further before I can tell more.

I'm also interested to hear more about the NavTech maps, so feel free to find out some details and let us know!

Kim

Well, Navtech covers the north america, western europe and a few asian countries at the moment. They have well over a thousand employees. They started out with the TIGER data, and they have dedicated drivers go out in pairs taking turns navigating and recording details of the road -- one way streets, intersections, etc. Every quarter, they manage to hit most of the roads to issue updates and changes to the road topology and are considered very accurate.

Garmin, Alpine, Kenwood, Rand McNally are all customers of their data.

Calvin

I have a day job that deals with maps, tracking and routing for an entirely different circumstance! (see attached) As you can imagine, it can be pretty busy. The news media has been pounding down our doors more and more lately -- they all want to know traffic conditions in the sky, historical backlogs and black box style "instant replay" information for flights, etc.

Calvin

I'll give them a call sometime next week. They are traveling at the moment.

Calvin

Any chance you might be able to get ahold of a UK map for the Blaupunkt RNS149? It uses NavTech data, but they don't sell the CD and I've had no luck getting one through Blaupunkt.

Of course if we had a more advanced nav project on empeg I could throw away the Blaupunkt

Rob

try to get Blaupunkt Part Number 7612100 069 (UK Map from 8/2001).

Peter

I think Jim answered your question best.

Calvin

Sven & Kim,

I spoke with Navtech regarding North American maps, and also west european maps for the purposes of testing. They can get a development copy of all maps for a low price, that can be even lower if you negotiate it down. They will be in contact with you to discuss terms, but the keyword here is that although Navtech doesn't do deals less than $75,000 -- they will call you and based on the projected price and number of users for the empeg navigation -- they can direct you to a partner company who can sell you onto a cheaper license. Basically, there are other companies in the position where they can't afford a full licensing so they split the cost.

Calvin

Update: UK 2002 will be available in April.

Peter