Android TextToSpeech Repeated Voice Instruction Queue Bug - Infinite Loop

[Archdoog]

When navigating on android, there are certain cases where the Android TextToSpeech wrapper starts reciting the same instruction after a re-route. Given the timing after re-route, this tends to be the initial "Depart" or "Continue on Something Rd." instruction. Notes about what happens:

1. For the first (or first couple of) occurrences (e.g. multiple re-routes) it will repeat the instruction several times, but the queue will eventually clear and appear to resume somewhat normal service.
2. After many occurrences, the instruction will be recited in an infinite (or near infinite) loop. Just saying the first instruction over and over again for the entire session until you either: mute, end navigation or funnily enough rotate the screen.

After this happens, even if you un-mute the next recitation will kick off a new cascade of repeated voice instructions. Given that we've taken some passes at this bugs, I'm starting to wonder if something's leaking, there's a thread safety issue. This guess is driven by the fact that initially it will self resolve, but later in the same session it often cascades out of control to an infinite-ish loop. Theory is if we're leaking something, we may have a listener that's running voice 1x per cycle, then 2x, 4x, 8x, and so on as more callers leak.

[ianthetechie]

Out of curiosity, did you encounter this around an off route recalculation?

I actually just thought of a few ways we can probably improve that and ensure users don't accidentally get in a loop making a bunch of useless reroute requests. I should be able to open a PR for that tomorrow. cc @ben-burwood since you may have hit one of those cases inadvertently too.

[ianthetechie]

Some notes after a look at this on the call today...

It seems that it is indeed happening around recalculation events anecdotally per both @Archdoog and @bjtrounson. We looked at the code and think there are possible race conditions in handleStateUpdate if the method is called from multiple threads. We haven't yet identified whether this is actually what's happening, but we should take steps to ensure this can't happen.

Additionally, we should probably store the Job returned by _scope.launch, as we store the task on iOS.

Finally, we noted that while we haven't yet seen this on iOS, there is definitely a possibility that the same bug exist, especially given that both implementations are as structurally similar as the platform APIs allow.

[bjtrounson]

As mentioned in our call today here is the recording of the behavior I got while mocking location updates down a route.

TextToSpeech_Repeating_Voice_Instruction_Bug.mp4

I know when mocking the route that the mock location app can give is quite simplified version of the route which I think might have caused the initial re-route here during the bend. My route deviation distance is also quite high at 250 at the time of this recording I've increased this since.

There seems to be once the initial re-route happens it fires off continuously after each other, which I think #453 would have solved.

I will look at getting the route information for this recording I did.

[Archdoog]

@bjtrounson even though you're correct that the gating bug fix should dramatically reduce or entirely avoid this bug. We should still try to reproduce the orphaned coroutine/race condition.

Would it be reasonable to post a branch with this reproduced in the demo app? E.g. a hard coded route request and simulated locations?

Happy to help get it set up.

[bjtrounson]

Yeah I've create a branch here that loads that same route https://github.com/bjtrounson/ferrostar/tree/text-to-speech-bug-reprod-route

I've hijacked the AutocompleteOverlay for this and that will load the route needed, I haven't done the simulated locations yet might need a little help with that haven't messed with the simulated mode before. All the data needed are JSON files in the assets directory I've created in the demo app.

The simulated locations should be the same as the one I created in my mock location app, it creates a very simplified version of the route so it's pretty inaccurate GPS wise but I think that what makes it good to reproduce this issue. It should be emulating a 120km/h speed or about 3333 centimeters a second as I think that's the speed I used in that video.

I've also set the NavigationControllerConfig to be the same as the one I used in that video.

I'm free if you want to jump on a call for this stuff if need be.

[bjtrounson]

I've added the simulated locations to that branch. The speed/resample rate probably needs increased for that route. Might also think about making this route shorter currently it's the full route that takes about an hour to go across.

A few things I have noticed while setting up the SimulatedLocationProvider, is the SimulatedLocationProvider meant to override the CourseFiltering.SNAP_TO_ROUTE option in the NavigationControllerConfig. It also seems the SimulatedLocationProvider doesn't stop once the navigation has stopped.

[Archdoog]

Sweet. I'll give it a play this weekend and we can plan to debug on the Monday call depending on how it goes. Thanks for the branch!

[Archdoog]

@bjtrounson this was super helpful to reproduce. Albeit a little amusing (I had to up the warp speed to like 150X).

Turns out the issue was:

#460 😅