bazzle wrote:Ive seen this on a couple of in car gps systems Ive fitted for people, even still on my wifes one.
Ive posted before and played with the sys.txt with no fix. Mainly on TTS phrases.
Ive been meaning to play with the sound file.
"Red light camera" becomes "... light camera" like you say.
What I am thinking of trying is to add an extra word to all the phrases. ie "[color="#FF0000"] A[/color] Red light camera" so when it drops the 1st word it wont matter.
If you do it or before me or find another fix please post back.
This is one I've heard on other forums. I think the file you have to edit is config_database.lua in the voice zip file, although I heard there was a way of overriding it in the sys.txt file, but no idea how. I read about it somewhere and it seemed like a great idea but I can't find the link now! This was the whole point of activating the Ding setting, but the problem is the voice is output too long after the initial Ding, otherwise it would work perfectly. I was thinking most instructions output by TTS are pretty easy to add something to, for example when it says : "Turn left at the roundabout, taking the first exit"
You could easily add a Now at the start so the sentence reads: "Now turn left at the roundabout, taking the first exit".
The initial word would take most of the delay out, but not be confusing if it was output as well.
chas521 wrote:I've seen this sorta work in other things but it might just help here also. In the TTS voice file, there is a file called "info.ini. Open that file and look for tts_rate=some number. Play with that number and see if it helps. Remember your old number just in case.
I'll try this tomorrow. I think they're 100 by default right?
I was thinking about this further and perhaps we've got this all wrong after all... On most forums, the suggestion is to switch the TTS priority to Very High or High on the CPU side, so it's processed as fast as possible and then passed to the head unit output. Think about it... the problem is that there is a lagg of some sort between WinCE and the bespoke implementation of the audio hardware, probably a delay in the mixer adjusting the output to the unit. When WinCE outputs any kind of audio, there is some sort of interrupt and the lagg is occurring due to a sound mixer delay on the WinCE hardware, probably caused by a delay in the threading.
So... surely the best thing to do is the exact opposite of high prioritization? By prioritizing TTS highly, the vocal audio is compiled quickly and output before the mixer settings have been adjusted and the interrupt is sent to the hardware. If we change the TTS priority to low or very low, the likelihood is that the compilation time will be increased, maybe not by much, but the mixer will have a set system priority so the interrupt will be sent at exactly the same time.
I will test this theory tomorrow, it may just cause the TTS audio to break up, but I imagine it won't because TTS is not about the output, but the processing
of text to speech.