Audio Issue on iPad but not iPhone

[zanesc]

Hi Halle,

I have read every topic on this forum about my issue and I have seen you mention it before but I have some new information that I would like to share concerning it that might help everyone who has had it before and might help you to debug it.

It is regarding the issue where an AVAudioPlayer’s volume is very low after speech recognition. I too am having this issue in my app. I know you have stated before that other users had no issue with AVAudioPlayer playing but there are still some topics with users who mention that they have this issue and had no solution to it (one person wen as far as raising the volume level on all of his audio files just to compensate for the audio volume drop).

I decided to create a new project (someone else mentioned they did the same but they never mentioned their findings). So i did, and this issue remained. The issue being if i start recognition, no matter if i use an AVAudioPlayer during recognition, after recognition has been suspended, or after recognition has been stopped completely, my audio volume never comes back to normal.

This was all tested on an iPad Air running iOS 9.3.3. I then decided to run my new project on the simulator (something i had not tried before with my old project which is why i never caught it). Low and behold it worked as you said it should. This confused me so i thought it might just be something different with the simulator. So i got my girlfriends iPhone (running iOS 9.3.3) and tried my new project on it…and it worked as well.

So TLDR it seems as this issue is confined to iPads (or at least my iPad Air running iOS 9.3.3). My guess is the other users who had the same issue were using iPads as well. I have no other iPad to test this on so i would like to know if you can test this on an iPad. You simply need to start recognition and then try to play an AVAudioPlayer while recognizing, after suspended, or after stopped. I have uploaded my test project to Github if you would like to skip the coding. https://github.com/zanesc/OpenEarsTest.git

You will see that i also added the only workaround that i was able to find to this issue. That is setting the AVAudioSessionCategory to AVAudioSessionCategorySoloAmbient. This has to be done if you want to play an audio file after you have started recognition on my iPad. But i say this is a workaround and not a fix because it comes with many caveats. It only works properly after you have suspended recognition. If you stop recognition and then try this workaround, the audio playing becomes VERY laggy. Sometimes it plays other times it does not and sometimes it only partially plays. Then after this is done the only way to get speech recognition to start back is by setting it back to AVAudioSessionCategoryPlayAndRecord before you start speech recognition. The other major caveat by doing this is that these calls take a relatively long time to take effect (a second or 2) and this can really mess things up.

Please look further into this issue. If you can not replicate it on an iPad i guess it only happens on some iPads and I will have to get another to test it on. This especially sucks for me because iPads are my main target audience for my application and i really need this working properly.

Thank you for your time, and keep up the good work.

[zanesc]

One thing i just noticed is, although the iPhone sounds play at the proper volume, there is a noticeable audio quality decrease after voice recognition is started as compared to before it is started.

[Halle Winkler]

Hi,

It’s quite possible that this behavior changes from iOS version to iOS version or device to device, but if session mixing is turned on and the audio object still behaves that unexpectedly (BTW, reduced sampling rate is not unexpected – OpenEars has to set the sampling rate on the session and if you play audio with a higher rate during OpenEars’ session, it may be downsampled – this isn’t documented in Core Audio but appears to have consistently been the default behavior across versions), that is a Core Audio bug or undocumented Core Audio behavior. As a result, although I’d like a different result as much as you would, it’s unclear what could be done about it by this framework, particularly if the behavior didn’t manifest in every iOS version or every device – I’ve documented that audio object coexistence during recognition is going to be very limited and problematic, although AVAudioPlayer is known to work with 16kHz PCM files since it is also a major element of OpenEars. I wouldn’t be surprised if there is different behavior with compressed codecs, although since these topics aren’t documented in Core Audio and appear to change over devices and iOS versions I’m not in a position to simply improve those results via troubleshooting for one version and one device (changing the default audio mode or using a non-recording mode as a semi-workaround is a non-starter, regrettably).

I can recommend taking a look at the new OEPocketsphinxController overrides added with 2.052 that are intended for improving Bluetooth device behavior when the Bluetooth device doesn’t exactly match up to spec:

disablePreferredSampleRate
disablePreferredBufferSize
disablePreferredChannelNumber

and convert your audio to a PCM format such as WAV, and see if the results are better. Consider trying out disableSessionResetsWhileStopped if this is happening after listening ends. Make sure to set these overrides before starting listening and after activating the OEPocketsphinxController instance.

[zanesc]

Hi Halle,

First of all thank you very much for such a quick response.

I am glad to report that one of your suggestions did it! It works now. I have tried everything you suggested and the one that made everything work was disabling the preferred sample rate! There also doesn’t seem to be any downsampling happening any more, my audio is playing at full quality while recording, after recording has suspended, and after recording has stopped.

Thank you very much for your support and keep up the great work. Maybe this is something you can add to the documentation in case anyone else comes across the issue again.

[Halle Winkler]

That is great news, now I’m even happier I added the override. I will think about whether it should be the default in a future version and/or extending the documentation about it to help with troubleshooting coexistence, and I appreciate your letting me know about your results.

[Author]

Posts