Headset forgets the first syllables of turn-by-turn directions. about osmand

[Biker729]

Habe alle Einstellungen - Entwicklungs-Plugin, Funktion vom Headsets und Bluetooth die ich gefunden habe getestet,

mit Einstellung „Wie Medien/Navigation“ wäre der Ton Perfect
aber die Erste Silbe wird unterdrückt bei Abbiegehinweisen weiter als 600 m (kurzer Ruhepause)

Mit der Einstellung „Wie Anrufe ……“ wird die Ansage korrekt angesagt, nur die Lautstärke ist zu leise.

Vielleicht findet ja noch jemand eine Lösung und kann sie mitteilen.

[sonora]

Yes, please enable the Development plugin, go to its Settings, select 'Test voice prompts', and use button 11.2 to toggle to a desired delay. If the phone call audio works for you as you say, a delay of 1500ms should work for your setup.

[Biker729]

Habe mit Simulation getestet,
bei den Abbiegehinweisen in kurzen abständen erfolgen die Ansagen korrekt,
bei Abbiegehinweisen nach > 600-800m (1-2 min) wird immer die Erste Silbe auch mit Verzögerung von 1500>3000 ms unterdrückt.
Sieht so aus als wenn das Headset nach kurzer Zeit in den Ruhemodus geht und zu spät erwacht.
Aber warum funktioniert es mit der Einstellung „Wie Anrufe ……“ ?

[sonora]

Hard to say, could be a "feature" of your headset and the bluetooth profile it selects to connect to these audio channels, perhaps in these cases prioritizing sound quality and power saving over responsiveness. (But I am just guessing.) Perhaps there is some setting for the headset to prevent this.

[jenom]

I actually have the same problem and it is not limited to Osmand but this happens with all navigation apps. I had this problem with two different bluetooth headsets and my ASHA hearing aids (BT 5). The connection is suspended to save energy when no sounds are played and the initial 500-1000ms are eaten up before connection resumes.

My current workaround is to let Tasker play a silent mp3 on loop whenever any of the nav apps are open but this is not ideal as this uses more battery and it changes the mode of my hearing aids. The delay test above does not seem to improve the cutoff for me.

What is probably needed is an additional silent sound before the navigation instruction is played, similar to my workaround. For my standard notification sounds I'm simply using sounds that are long enough or start with a long enough silence.

(I'm using the call output and the volume seems to be good but it might be different with HAs).

[sonora]

@Biker729 , @jenom Have you tested the voice prompt delay (toggle via button 11.2 in OsmAnd's Development plugin) and made sure you have really set the delay for the very output mode you are using?

This advanced feature is exactly designed for issues like this.

[Biker729]

Mein Problem mit zu wenig Lautstärke bei korrekten Navi-Sprachansagen
habe ich mit diesen Einstellungen beseitigt.
Bild 1-3

[sonora]

Still not sure if you ever tried #19906 (comment) ?

[jenom]

@Biker729 , @jenom Have you tested the voice prompt delay (toggle via button 11.2 in OsmAnd's Development plugin) and made sure you have really set the delay for the very output mode you are using?

This advanced feature is exactly designed for issues like this.

Hi and thanks for the reply. I've tried the setting and it does change the delay but it also just shifts the cutoff point unfortunately. So I still get the same message cutoff in the same position in the beginning but 3s later (for 3000ms). So the actual sound comes only after ~3.5 - 4s and starts mid sentence.

I think, unless it actually produces a (silent) sound stream for the delay, this will not fix the cutoff. I've tested this with both media and call outputs and the results were the same.

[sonora]

@jenom Thanks for testing! This is for a TTS voice, I understand? Could you check a recorded voice for a test, just to see how that behaves?

Also, re-pairing the BT between your phone and the hearing aids may solve the issue, or perhaps testing an intermediate device like the Philips Audio Clip.

I will go to the code and check how I had once implemented the delay, but am quite certain that for e.g. TTS voices it is implemented as "playSilentUtterance". So perhaps that seeems not enough to "wake up" the aids.

Also, since this seems a universal issue for all notifications, I think the manufacturer of the HA should be contacted? Are you using their latest firmware?

Plus: Do they offer an app to configure the ASHA protocol on your device? Some manufacturers seem to do... not all ASHA capable devices seem to have equally mature and configurable ASHA support out of the box.

[jenom]

Thanks @sonora a lot for taking the time!

@jenom Thanks for testing! This is for a TTS voice, I understand? Could you check a recorded voice for a test, just to see how that behaves?

I just did the test and It seems to behave the same with the prerecorded messages. Also the shift happens the same.

Also, re-pairing the BT between your phone and the hearing aids may solve the issue, or perhaps testing an intermediate device like the Philips Audio Clip.

Unfortunately, I don't have such a device as they are super expensive and not needed anymore. However, I had one for my old HAs (which did not have Bluetooth by themselves) and this older Bluetooth dongle which only supported the SBC codec did behave in the same way when I used it with Komoot/Maps/etc. It was also the same on my last phone. Hence, I already had the Tasker script as a fix. I also once tested (not in OsmAnd) with Aftershocks and they did the same.

I will go to the code and check how I had once implemented the delay, but am quite certain that for e.g. TTS voices it is implemented as "playSilentUtterance". So perhaps that seeems not enough to "wake up" the aids.

Thanks a lot for the effort. As the prerecorded voice does have the same behaviour, I reckon that the delay is implemented without actually playing a sound there? I think, it might not be enough to "wake" the sound device but one actually has to send some audio data. This should work as my Tasker script does exactly this.

Here somebody else suggested this solution and it seems to have failed there but I assume that the audio is never produced as playing the silent mp3 is treated the same as playing proper audio files for me.

Also, since this seems a universal issue for all notifications, I think the manufacturer of the HA should be contacted? Are you using their latest firmware?

Plus: Do they offer an app to configure the ASHA protocol on your device? Some manufacturers seem to do... not all ASHA capable devices seem to have equally mature and configurable ASHA support out of the box.

They are very new and up to date. ASHA is a little weird under Android as it bypasses most audio settings including all the Bluetooth settings in the Android developer options. The app only allows to change HA programs and sound settings etc., nothing technical. They work as expected otherwise which includes a 1/2s latency for real time applications as is typical with Android. They are Bluetooth LE but as stated above my old BT bridge did the same (which was ancient BT 2.x I believe).

For completeness, here is the very simple Tasker script that starts as soon as OsmAnd is running:

I guess, a similar solution would be to create and empty audio buffer of the desired length and play that before any of the notifications.

[sonora]

I have looked up my 2016 code of delaying the audio output, here's what it does:

If the voice engine is not already initialized:

1. Initialize Audio Focus, Audio Manager, Audio system service. Set Attributes like usage, set content type, etc. If focus is granted:
2. If output type is phone call simulation, attempt Bluetooth SCO (Synchronous Connection Oriented link). (has 2 meanwhile deprecated methods - will update)
3. If an output delay is requested for the selected audio stream:
   3a. For the TTS case, playSilentUtterance() for the selected delay
   3b. For the recorded voice case: pause the thread for the requested delay

If focus is granted:

4. Play command queue, stop engine when empty. Then abandon Audio Focus.

So it seems that in the case of your setup or hardware,

• (1) seems not enough to 'wake' the hardware from its standby state.
• (3b) may perhaps be enhanced to play a "silent mp3" instead of just pausing the code.
• But focus should be on the TTS case, and it seems that the Android method playSilentUtterance() seems to not "wake" your hardware (although I would guess that's one of its purposes). Would not off hand know what could be used instead...

Any chance you contact the manufacturer and ask them this specific question?

Also, as of Android 15 Google has introduced support for a new standard called LEA (Low Energy Audio) in addition to ASHA. While it is a universal standard of streaming audio over Bluetooth it’s also expected to deliver more efficient hearing aid management features. So perhaps your devices may receive a software upgrade.

[sonora]

PS: I have made the small update adjusting (2) for Android 12 and up, so if you are using Android >= 12 it may be worth re-testing the Voice guidance output "Phone call audio" on a new OsmAnd nightly build or next release to see if it has any effect.