Hi,
OK, I can attempt to see if I can help with this if we can isolate the cause a bit more. I can’t give any assistance with memory managing the singleton – it will create many side-effects and divergences from the normal behavior of the library since the library is developed and tested on the assumption that its memory management is as it is, and I’ll have the problem of supporting anyone else who goes that route as a result of reading this discussion, meaning that I will be heavily supporting Unity and in a uniquely architecturally weird implementation, so I have to decline to pursue that request further, sorry. It is also not guaranteed to help, since the issue above is with the audio session, and that would persist through any changes in OEPocketsphinxController because the audio session is a singleton from Apple.
What is happening there in your logging as far as I can see is that some part of your Unity implementation is creating a race condition to the audio session or another aspect of the audio environment – perhaps two things are listening for audio changes and reacting to them, one of them being OpenEars and the other being part of Unity. There’s no info yet in your issue report about what else is happening with audio in your app. So the first step to trying to isolate the behavior into something that I might be able to help with is to find out what part of the rest of your app is colliding with OEPocketsphinxController’s management of its audio state –– see if there is anything you can turn off which changes the behavior. The other thing that is quite important is turning on verbosePocketsphinx so that your logging is complete, and showing your entire app session’s OpenEars logs rather than editing it down, because there is no way to know at what stage in the logging something significant to the issue you are seeing will happen.