Issues when playing sound by OpenAl by upgrading Openears to 2.504

[xwang]

Hi Halle,

We are using Openears + rapidears + Rejecto.

We play sounds by OpenAL in our App, it works perfect with Openears before.
Recently, we update our Openears from(2.5x) to newest version(2.504 according to change logs).

We can’t play any sounds after updating. I have tried setting AVAudioSession category to AVAudioSessionCategoryPlayAndRecord, still no works.

If i set category to AVAudioSessionCategoryPlayback, sound played normally, but OpenEars can’t work under that category.

Actually, if we used the version of OpenEars we used before that would not be a problem(we got the idea recognition rate we need and played sounds well),

but we purchased RapidEars and Rejecto under a new bundle id recently, and i just found that the RapidEars we got is the newest version which just can’t adapt to that old version of OpenEars we uesd (it crashed when startRealtimeListeningWithLanguageModelAtPath, fortunately, new version of rejecto still works fine).

So the problem is, if we used the new version of Openears, we can’t play sounds, if we used the version of Openears we used before, we got the sounds played, but crash when we use new version of RapidEars.

Do you think it is the problem of Openears, so you can fix that? I mean since we can play sound with same codes before. Or it is not under the range of you assist with?

Or can you just give us the old version of Rapid Ears? I think it is 2.5.

Thanks,
Xi.

[Halle Winkler]

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.

[Author]

Posts