February 24, 2014 at 10:15 pm #1020308
I’ve got my app(s) updated and submitted to Apple for approval (finger’s crossed) and I’m starting in on generating a couple of video how-to guides on the app.
I’m using the MAC OS software called AirServer to Airplay the screen from my iOS device to my MAC to record. The problem I’m running into is whenever I have an active Airplay connection and I turn the mic on (activate OpenEars), the AirPlay connection is dropped until I turn off the mic (tell OpenEars to stop listening).
Any ideas about what I can do to keep the Airplay connection active while using OpenEars?
WesFebruary 24, 2014 at 10:39 pm #1020309
Ok, found a partial workaround from: https://developer.apple.com/library/ios/qa/qa1803/_index.html
Looks like iOS doesn’t let us do Airplay if we’re using the “VoiceChat” OpenEars option. Any of the other 4 options will allow Airplay, but then I lose the ability to play sounds from the app using the AudioServicesCreateSystemSoundID method. Specifically, iOS disables Airplay when using the AudioSession property: AVAudioSessionModeVoiceChat
For now this will work for my demo video. The sound from the app isn’t necessary.
If you happen to know of a combination of settings the .audioMode property that allows for speech recognition + sound playback + Airplay, I’m all ears, so to speak. My guess is that I’d need to change how I’m playing sounds and move away from the AudioServicesCreateSystemSoundID method.
WesFebruary 25, 2014 at 10:43 am #1020317
Sorry, I really don’t know the answer to that one – the audio modes are offered on an as-is basis since trying to find all their quirks with different configurations would be prohibitive in terms of time, especially since they can also change in iOS releases.February 25, 2014 at 10:45 am #1020318
My standard piece of advice for doing repeated short sounds is always to put them in an AVAudioPlayer that has been prepared to play or played silently once, since it doesn’t raise the same compatibility issues as AudioServicesCreateSystemSoundID (which compatibility issue is one of those quirks I mentioned).February 25, 2014 at 6:24 pm #1020340
I did a little experimenting, and AVAudioPlayer works on the local iPad device and when Airplaying to another source, however, AVAudioPlayer has a bit of a delay (maybe 0.2 seconds) in playing the audio even after calling prepareToPlay. Seems like that’s the nature of this mechanism.
In my case that wasn’t acceptable to convert over 100%, so I’ve gone back to using AudioServicesCreateSystemSoundID which give a nice immediate sound effect when only on the iOS device (no airplay).
The workaround for anyone else reading is I look at the number of screens connected to the iOS device by calling [UIScreen screens]. If more than one (Airplay) then I configure PocketSphinx as the “Default” audioMode and use AVAudioPlayer to play my sounds. If there is only one screen then I configure PocketSphinx as the “VoiceChat” audioMode and use the AudioServicesCreateSystemSoundID method to create and play sounds.
Not a perfect solution, but I figure that a little delay on the rarely used AirPlay mirroring is acceptable. 99% of the time the users would never run into this case and they get the optimal sound performance.
WesFebruary 25, 2014 at 6:47 pm #1020341
Sounds good, and thanks for documenting it for other readers.
- You must be logged in to reply to this topic.