Hi Xi,
So, it’s never been supported to use another audio framework simultaneously with recognition (it’s actually something I’ve actively advertised as being unsupported here and in the FAQ), but I understand you had something that was nominally working previously. Like I explained in the previous question, it isn’t possible to give you or support older versions, so unfortunately that is ruled out.
The audio changes from 2.5 onwards increased compatibility for mixing cases rather than decreasing them, so the most likely cause of your emerging issues is too much intervention, i.e. where you explain that you have set the audio session category, which is something you can’t do with OpenEars and its plugins, and I’d guess there is probably more forcing of audio settings OpenEars needs to set for itself that was part of making it work in the older version.
This is something that you would need to troubleshoot locally with your team since I don’t support this scenario or maintain a testbed that could even help me give you input on it, however I am happy to give advice about how I would approach the problem for the best results if it were an issue I had on my plate. Step 1: return your integration of the two frameworks to a simple/naive state. That is, whatever you had to manually override in the audio settings/session to get them working together (i.e. any audio session overrides), please un-override it as if you had just tried them together for the first time. A good rule of thumb is that a case-insensitive search of “audiosession” in your app code shouldn’t find anything. A few of your forum questions are about audio session issues from combining OpenEars with unsupported audio frameworks, so you could have a couple of iterations of this kind of code. Step 2: Take a close look at the documentation for OEPocketsphinxController 2.504, which in addition to having an 8k recognition mode option now, also has four properties that could affect audio coexistence: disableMixing, disableSessionResetsWhileStopped, disablePreferredSampleRate, and disablePreferredBufferSize, and try them out to see if they help (making sure you’ve already made the shared OEPocketsphinxController object active before interacting with any of its properties).
A simpler alternative would simply be to use a primed AVAudioPlayer for playback since it is supported (again, making sure that nothing, including the AVAudioPlayer, is making calls to the audio session). I’ll leave this open so we can discuss results a bit if it’s understood that I can’t discuss the issue of producing old versions of any of the software further, or the question of whether this kind of audio coexistence should be supported/supportable, thanks.