Welcome,
Sorry you’re seeing an issue. The reason that I’ve labeled the bluetooth support experimental is that I can’t test against every device, so I do think it’s possible that it can happen that a particular device has quirks. The good news is that so far, this is actually the first time a developer has reported an issue with a particular bluetooth device in combination with the sample app since I added bluetooth support a year ago, so please treat it as a bug report and show me the full logging output from the sample app if it manifests the same issue and let me know the device, and if the opportunity to test and fix it comes up I will do so. I’d appreciate getting to see the full OpenEarsLogging output and the verbosePocketSphinx output since that will tell the whole story.
It does sound like there could be a general configuration issue in your own app if it performs notable differently from the sample app — I would investigate whether your app makes changes to the audio session either by calls to AVAudioSession or lower-level audiosession calls since that is the most likely way for an app to change OpenEars’ audio handling. Something else that will change the audio session is using certain media objects such as video players or some audio players. The last thing that I think might lead to issues is if you are doing anything that might override OpenEars’ threading behavior.
You can always access the source code and change it and recompile it for your own app — the framework source is right in the distribution in the OpenEars folder.