Hmm, this doesn’t quite look like a simple bluetooth issue (you can see that the bluetooth route is switched to and that the audio unit starts and has no audio render errors). Here is what looks off to me, later in the logging:
2014-12-08 18:16:14.476 MyAppName[250:17184] resumeListening 2014-12-08 18:16:14.782 MyAppName[250:17184] pocketsphinxDidStartListening 2014-12-08 18:16:15.334 MyAppName[250:17184] resumeListening 2014-12-08 18:16:15.334 MyAppName[250:17184] Valid setSecondsOfSilence value of 1.500000 will be used. 2014-12-08 18:16:15.339 MyAppName[250:17184] suspendListening 2014-12-08 18:16:15.428 MyAppName[250:17184] pocketsphinxDidResumeRecognition 2014-12-08 18:16:15.429 MyAppName[250:17184] pocketsphinxDidSuspendRecognition 2014-12-08 18:16:17.068 MyAppName[250:17184] resumeListening 2014-12-08 18:16:17.068 MyAppName[250:17184] Valid setSecondsOfSilence value of 1.500000 will be used. 2014-12-08 18:16:17.069 MyAppName[250:17184] pocketsphinxDidResumeRecognition INFO: ngram_search_fwdflat.c(302): Utterance vocabulary contains 0 words
What is causing the repeated suspend/resume in the timeframe in which you’re expecting speech?
Can you use your bluetooth device as input either with a tutorial app or the sample app? You can change the bundle ID of the sample app in its info.plist property “Bundle identifier” and the volume output of the sample app should make it clear whether the bluetooth mic has input.
OpenEars 2.0 works with my bluetooth devices and with this developer’s:
https://www.politepix.com/forums/topic/small-bug-when-running-on-ios-8/#post-1023307
So if the headset follows standards and is able to use its mic input outside of calls (not every bluetooth headset can do that), it ought to work. Does it work with other 3rd-party apps which can use bluetooth mic input?