Poor Recognition after Stopping & Restarting

[benwirz]

Hi Halle,

I’ve upgraded to OpenEars 2.03. I also have Rejecto 2.03 installed but I’m seeing the same problem regardless of whether I use the rejecting model or not. After I first start recognition, everything works perfectly as the 1.xx version did for me. After I stop recognition as I do when moving to the background or getting an audio interruption and then start it again, the recognition results are extremely poor. I tried to debug the problem for a couple of days with no luck so I finally decided to install SaveThatWave (2.0) which shed some light on the issue. The initial recordings sound fine but the recordings after stopping and then restarting the controller are significantly distorted. They sound like they are being played back slowly leading me to believe the sampling rate is incorrect or something along those lines.

I’ll post the log and a link to the recordings for you next.

Thanks,
Ben

[Halle Winkler]

Hi Ben,

Since stopping and starting is known to work, this is more likely to be due to the interruption or backgrounding. Can you create a replication case for this (with very clear instructions for replication) following the instructions here:

https://www.politepix.com/forums/topic/how-to-create-a-minimal-case-for-replication/

I’d recommend basing the case around stopping, going into the background, going into the foreground, and starting. That will let me investigate your report with other interactions from the app ruled out.

[benwirz]

Hi Halle,

Thanks for the instantaneous reply! Just to make sure I understand correctly, should I execute [OEPocketsphinxController sharedInstance] stopListening] in the appWillResignActive notification or appEnteredBackground notification?

I noticed the example app doesn’t do this but I used to get the Red Bar across the top after pressing the home button if I didn’t send the stopListening in the previous 1.x versions so I left in it for the new version as well.

Thanks,
Ben

[Halle Winkler]

Just to make sure I understand correctly, should I execute [OEPocketsphinxController sharedInstance] stopListening] in the appWillResignActive notification or appEnteredBackground notification?

That is your call – I don’t actively support background mode usage of OpenEars which means I don’t test against it or recommend approaches for it; there are so few API promises from Apple about what is supposed to happen there and it is assumed to be a best-effort service, so I can’t take on a higher level of obligation about it when I have no control over that. However, if something used to work in 1.x and has stopped in 2.x, I would like to fix it if I can.

What you should show me is the closest thing possible to what used to work, but in the simplest possible implementation, based on the sample app with as few changes as possible. That way we can disengage it from your other app implementation details and we’ll both have a simple and repeatable reference point for discussing it. You may also discover in the process that it works better with the sample app, which might give you a hint about how to change the unwanted behavior in your own app, but either way I’ll take a look at what you have to show me.

[benwirz]

Hi Halle,

My app doesn’t run in the background and I’m not trying to do background recognition. Not sending [OEPocketsphinxController sharedInstance] stopListening] in the appWillResignActive solves the problem for going to the background and returning from the background. I also don’t get the get the red bar across the top like the previous 1.x version. I’ll test the audio interruptions next.

Thanks
Ben

BTW I understand the necessity of creating a simple test case and I’m happy to do so if required but I just wanted to make sure that I’m using it correctly before going to the effort of putting a test case together for you.

[Halle Winkler]

BTW I understand the necessity of creating a simple test case and I’m happy to do so if required but I just wanted to make sure that I’m using it correctly before going to the effort of putting a test case together for you.

I totally understand, I was just (over-)clarifying, but I also didn’t realize that you weren’t doing background listening. I’ve been getting a lot of reports about background listening this month so I am probably tending to assume. You’re correct that it should be able to cope with stopping, backgrounding, foregrounding, and starting from a stopped state, since from the app’s perspective only foreground operations are actually happening.

OK, so do I understand correctly that the symptom improves for foreground/background when you make the stopListening call in a different method, and now we’re just looking into pre- and post-interruption behavior?

[benwirz]

Hi Halle,

The symptoms goes away if I DON’T make the stopListening call when going into the background. Now I’m only calling stopListening during an audio interruption or route change. I believe that my AVAudioPlayer instances were interfering with the stopListening in some way. I had been stopping the instances right before making the stopListeningCall. The trick turned out be to stop them in the didStopListening delegate call back. This way I only try to stop them after I know OEPocketsphinxController has itself stopped avoiding the conflict. This seems to work fine for the audio interruption related situations but for not going to the background.

I think this solves this issue, thanks for your help!

-Ben

[Halle Winkler]

OK, glad to hear it! I’ll review what is happening with real interruptions in any case (I do automated testing against a simulated interruption) and make sure that the default behavior is as expected.

[Author]

Posts