That log also shows that the framework is successfully setting up the bluetooth route with the device, so I don’t have too many suggestions left.
I read up on the device and many users were complaining that it couldn’t be used for watching video because the audio is very high-latency, so that sounds like it has an idiosyncratic i/o compared to the usual BT headset behavior. That means I can’t troubleshoot it from afar since I have no insight into the device, the device implementation, or Apple’s implementation of how it initializes bluetooth for an audio unit. I’d do the following:
1. Test with other (known-to-work-with 3rd-party audio input) BT devices to sanity-check. I have a Samsung HM1300 that is not high-end (in fact it cost €10) and it does i/o perfectly with OpenEars 2.0, so that’s a good test device, or you can ask the developers with working bluetooth what they’re using.
2. Check out whether you are running the current version of your headset firmware. They have firmware update instructions in the support section of their site.
3. See if you get any different results setting different values for OEPocketsphinxController’s audioMode property.
4. If you feel up to recompiling the framework, you can try to change things in this line:
[sessionInstance setCategory:AVAudioSessionCategoryPlayAndRecord withOptions:AVAudioSessionCategoryOptionMixWithOthers | AVAudioSessionCategoryOptionAllowBluetooth | AVAudioSessionCategoryOptionDefaultToSpeaker error:&error];
For instance, I would see what happens when you remove AVAudioSessionCategoryOptionMixWithOthers and AVAudioSessionCategoryOptionDefaultToSpeaker as options so it looks like this:
[sessionInstance setCategory:AVAudioSessionCategoryPlayAndRecord withOptions:AVAudioSessionCategoryOptionAllowBluetooth error:&error];
And you could try changing the settings in handleRouteChange: so that either all of them perform the route change operation, or all of them don’t, in order to see if it is related, by changing this line:
if(performChange) {
To either this:
performChange = FALSE;
if(performChange) {
or this:
performChange = TRUE;
if(performChange) {
Remember that the framework now needs to be built by choosing “Archive”. Let me know your results.
5. I’m not at all pushing this as a solution because the headset is very expensive, but if you are very committed to my being able to test it, I can add it to Politepix’s Amazon Wish List and you could buy one for Politepix (used is fine). This wouldn’t be an agreement on my part to make it work/always keep it working (this kind of situation and the expensiveness/diversity/closed-ness of bluetooth devices are the exact reason that bluetooth support is experimental in OpenEars), but my being able to run it would certainly be the most likely path to making it work and I would agree to give it some debugging time and see what’s possible. Before doing this, I would very strongly recommend that you verify that the input on your device works with another 3rd-party app as a low-latency audio input device on the same device and iOS version, i.e. recording voice memos or similar, keeping in mind that if a 3rd-party app can’t really use your headset, it is likely to default to the built-in mic and perform some kind of recording anyway, so it’s important to verify whether the recording is coming from your headset or the built-in mic.