Forum Replies Created
Hey Halle, I just got my hands on an iPhone 5s. The VPIO handling on the 5s definitely has some bugs and when playing audio, it will play it haltingly. This was not a problem for 4s or 4 on iOS7 (have not been able to test on iPhone 5 or 5c). I can see why you removed VPIO support and maybe that was a good idea! I think I will just have to focus on remoteIO.
Yes, let’s wait on the bounty. Incidentally I did try setting up a very basic VPIO mode app (I just edited the “AurioTouch 2” sample code from Apple and created some buttons to play a sound at a known volume level). Sound volume is definitely lower in VPIO mode. I think this is normal to have it be somewhat lower to allow for optimal echo cancellation. However I think it is way too low.
On the low volume for VPIO. More people have been having this problem:
These seem to be about recording volume with some thoughts on output voluem too. Lot of people are saying it is a bug:
I just changed the order of events and made sure audio session mode was being set AFTER default speaker was set. It did not increase the volume.
It would be interesting to see if there were 2 audio units, but I’m not sure if even the person who created the answer solved his own volume problem with it.
I upvoted the answer and am getting friends to upvote it as well. I would gladly put more bounty on it, but I couldn’t find the bounty button after I edited the question. I think maybe because there is already a bounty on it?
I might check this out by first writing a _really_ simple app that does nothing but set up a VPIO
I would actually like nothing more than to do away with remoteIO completely and just use VPIO if not for the volume thing. I would love to do your suggestion, but my core audio is mediocre at best, so it would be hard for me to even build a simple core audio app (but I will try!). Any tips on general steps would be helpful!
Does it help if you give whatever you are playing back an explicit volume level?
I could try to give an explicit volume level, but I’m not sure how to do this in the low level core audio stuff. I only know how to do this with the high level AVAudio APIs.
Are things quieter with echo cancellation on, or whether it’s on or off?
There is a audioUnitProperty kAUVoiceIOProperty_BypassVoiceProcessing that supposedly bypasses echo cancellation while in VPIO, but things are still quiet regardless of this. Is that what you mean?
Good to know, this [VPIO] should probably be reexamined.
Please do soon!!!
The echo cancellation works perfectly. It’s amazing. I have checked and made sure that sound is definitely coming out of the speakers in VPIO mode. That being the case, do you still think the order of the override matters?
The reason for allowing them to switch is that VPIO seems to drastically reduce the output volume. I’m not sure if it’s a bug or if I need to set other audioUnitProperties but it makes it EXTREMELY low volume when using VPIO. I also noticed that in iOS 5 the volume for VPIO was much louder (but still softer than when using remoteIO).
Thanks for the insights Halle. I do use the audio session modes, but what I’m really looking for is noise cancellation because the app plays sounds while it still has to listen for voice commands… If you have any thoughts on noise cancellation other than using VPIO, I’d really appreciate it.
I use the VoiceChat audio session mode with VPIO:
AVAudioSessionModeVoiceChat Specify this mode if your app is performing two-way voice communication, such as using Voice over Internet Protocol (VoIP). When this mode is in use, the device’s tonal equalization is optimized for voice and the set of allowable audio routes is reduced to only those appropriate for voice chat. For use with the AVAudioSessionCategoryPlayAndRecord audio session category. Apple recommends using the Voice Processing Audio Unit with this mode (see Audio Unit Hosting Guide for iOS).
Halle, the reason I ask is because I’m finding a weird bug as I move my app to iOS 7. To give some background, I made changes to the OpenEars classes that would allow my app to start pocketSphinxController in RemoteIO audioUnitSubtype or VPIO audioUnitSubtype. In the app, I could dealloc the pocketSphinxController instance and reinstantiate pocketSphinxController in another audioUnitSubtype dynamically.
This would work fine in iOS 6. While a user was in app, they could switch from VPIO to listening in RemoteIO mode and back.
However when the same app now loaded in iOS 7, the user will set the variable to switch from VPIO to remoteIO but it seems to stay in VPIO mode despite all the variables being passed correctly. I know it is being passed correctly because if they app is then terminated and restarted, it will be in RemoteIO mode.
I hope this wasn’t too confusing. Basically what I’m saying is that in iOS6 the same code allows users to switch between VPIO and RemoteIO seemlessly, and yet when loaded on iOS7 it will only switch if you terminate the app and restart it.
Thoughts? Is there any OpenEars classes that remain on the stack whenever a pocketSphinxController instance is dealloced and reinstantiated? Any help at all would be appreciated. I hope that this isn’t just some random iOS 7 bug in Core Audio…
Using OpenEars 1.5.2.
I think that would be really great to simplify the code and I would be 100% for that sooner rather than later. If anyone is still using iOS 4, I feel sorry for them but progress must occur!
Thanks for the quick reply as always Halle!
Thanks Halle. The reason I set the audio session mode to video recording is because I use voiceProcessingIO so users can give voice input while sound is playing, but this significantly decreases the output volume (when compared to remoteIO). I’ve found that by setting the session mode to “video recording,” the sound output volume is much better. But now I realize that there are some disadvantages as well.
Thanks for the response. What do you mean by “less sensitive default settings?”