Hi,
Thanks for the additional output, but I don’t think it is productive to focus on route changes since the issue is happening at any call to stopListening() in your report. A route change is just one thing that is resulting in a call to stopListening, so looking at the Unity route change behavior means that we’re focusing on something with a non-causal relationship to the behavior we’re troubleshooting (i.e. although a route change is present when stopListening doesn’t work, the route change is known to be a bad candidate for being the reason for stopListening not working because there are no other situations in which stopListening works).
IMO the case to check out would be the most minimal possible failure of stopListening, i.e. starting the app, immediately starting listening, possibly recognizing a single word, and then stopping with a stopListening failure, and then stopping the app. At that point we’re interested in all of the possible Unity audio output about what it is doing when listening is started and stopped, and seeing the entire OpenEars logging output for the entire (very short) app session.