Important announcement: TAAE and the iPhone 6S
Hi folks,
I've got an important announcement for you about the iPhone 6S.
tl;dr: If you can, test your app on a 6S. If it's not working (or if you're in doubt), update your TAAE version.
Revision for clarity: If your app does not record audio from the mic - you're probably all good. This problem mainly affects mic input.
Turns out, the 6S (and the 6S Plus) is a tricky little device: unlike those that have come before, the iPhone 6S's hardware sample rate cannot be changed when there's no headset or audio interface plugged into it: it's jammed in the 48 kHz position. What's annoying is that in certain circumstances there are mismatches between the input and the output frame count for any given time interval. This is probably due to the need for sample rate converters, but it's causing havoc with many apps, including some of those built with TAAE.
I've just fast-tracked a new TAAE release (1.5.1) which accounts for these mismatches, and have submitted a version of Loopy with these changes for testing.
Note: this isn't thoroughly tested yet, because I thought it a better idea to get it out to you now. Please do take it for a spin, and let me know how it goes.
You can grab TAAE 1.5.1 from Cocoapods, or the Github repo. You can see the set of changes on the Github page.
This problem also affects Inter-App Audio and Audiobus; we've got an internal Audiobus SDK build that's now working, and we'll get that out to you as soon as we can (only output apps will need this update).
While I've got your attention: you may have noticed the iPad Air 2 has truly enormous playthrough latency. If you've got an audio app and audio sync is important, I strongly recommend setting AEAudioController's automaticLatencyManagement setting to YES. This will be on by default soon.
Cheers!
Michael
Comments
Does this affect apps that doesn't use input and playthrough? I don't have a 6Plus under my belt so i can't tell if it affects our app for sure
https://itunes.apple.com/us/app/the-piano-3d/id771068869?ls=1&mt=8
Cheers
It's a bit hard to tell, I'm afraid (I've not surveyed many apps), but I don't believe so. I've grabbed the app to check it out on my 6S Plus; it's downloading now. Stay tuned.
Oh, thanks! And thanks for the awesome SDK by the way, we've got it to work flawlessly with Unity3d and it's Fmod audio engine. Endless possibilities there!
No worries!
Seems to work just fine! Beautiful app, btw
Michael,
Along these lines: I just wrapped up internal testing on my latest build, with everything going swimmingly. I was about to post the build to Testflight, and then saw this thread. Now tomorrow I'll need to update to 1.5.1 and make sure everything is still good.
I don't yet have access to an iPad Air 2 nor an iPhone 6S, so I have two questions:
1) Previously you mentioned that the iPad Air 2's main issue was playthrough latency when using the handset microphone and speaker at the same time, but it was ok when using a headset. Is this still the case? I tried the suggested fix (measurement mode), but it wreaked all sorts of havoc in my particular setup. So I force TAAE to NOT use measurement mode when using the handset mic and speaker, and all is OK. The ideal use of my app is with a headset, so I'll just have to remind folks that have Air 2s to always go that route. Or does this automaticLatencyManagement setting REPLACE the measurement mode fix? If so, that would work in my favor.
2) For the iPhone 6S, I'm currently locked into 44.1KHz, and will have to rewrite some encoding/decoding code to switch to 48KHz. If I post to Testflight using TAAE 1.5.1, would you be up for giving the app a spin on your 6S to see if it has any issues? I'd be honored to send you an invite and get some feedback. Your engine has allowed me to do some pretty amazing audio synchronization across multiple devices.
Have a good one!
Hey @wdinkel. D'oh! That was bad timing
You may still be fine, though.
It is indeed: headset seems to stop the issue. automaticLatencyManagement only helps with recording - it doesn't affect live playthrough.
Sure thing (although I can only promise a cursory test, to make sure the audio's correct) - I'm michael at atastypixel dert com.
Hi Michael:
Well this is a Biggie since we were about to ship the New LOOPACKS Version. I GUess I Can Update Both TAAE and AUDIOBUS and Give the App an OverAll Audio Test before Shipping.
Regarding those Versions: is TAAE 1.5.1 and the New AB Beta version ready for Release? I guess I Mean if it has been checked backwards with Devices like iphone 4s and the likes...
I Just want to try and minimize the Damage as most of us :-)
I'll send you an Email Once I Have the Version Ready for BETA.. Thanks
And KUDO's for catching those kind of problems even Before the iPhone 6s Hits the Stores :-D
Hey @Hernan,
Yeah, it's a major pain in the ass! Note that if you don't record mic audio, and you do not receive audio from Audiobus, there's probably nothing you need to do right now. I noticed that Loopacks only has a sender port, so I suspect you're probably in that category (lucky you!).
If I'm wrong (or if you wanted to update stuff anyway), then:
In a word: sorta. I've hurried to get an update out to you guys, but it is relatively untested at the moment. I've got both TAAE 1.5.1 and the AB SDK beta in a version of Loopy that's in testing right now (and in the App Review queue, at the same time), and I'm not hearing anything bad just yet, though.
Cheers
Cheers Michael for the good work. I have been wondering about the iPad Air 2 for a while now. Just have a small question about the iPhone 6s sample rate. So, does this new TAAE version mean that I can still run my app at 44100 and it compensates for the mismatch or would I have to account for the change in my sound engine and process for 48000?
Thanks
ERik
No worries @humbleTUNE
That's right - it'll automatically compensate, so there's nothing you need to do except update.
Michael,
Thanks for offering to test! I got 1.5.1 working just fine today. I'll post the latest build to TestFlight tomorrow and send an invite.
One minor issue: it seems that VPIO doesn't really take effect on iPhone 4S or the 1st gen iPad Mini. If I unmute the mic I get instant mass feedback from the device speaker. The same settings work as expected on an iPhone 5S, though. Is this just a limitation with those older devices, or am I maybe missing a setting? (Currently initializing AEAudioController with input enabled, then enableVoiceProcessing to YES, then useMeasurementMode to NO).
I'm afraid I don't know! I've never tested VPIO with those devices..could be they simply don't have it.
Brilliant @Michael!
Thanks again for making life easier, when apple makes it harder.. I shall start updating my apps then.
ERik
No worries!
Michael, thanks for your work on this update. I'm having an issue after running pod update this morning. I had a couple build errors and had to change a couple lines to match the updated syntax around updating the audio description, not a big deal, but the real issue is now I'm getting pointer related runtime crashes (EXC_BAD_ACCESS).
I'm wondering if this is thread related, as were occasionally seeing the error message about not having more than one instance of TAEE. I've tried initializing TAEE on the main thread as well as using lazy instantiation, but still crashing shortly after launch.
My app is written in swift 2.0 for iOS 9.0 and has been using TAEE without issue until the latest cocoa pod update
Can you be more specific, @johnnyclem?
Michael - I'm not using TAAE for microphone input (pulling directly from remotIO) when i set my client format to 44.1 the audio pulled from the mic is slightly slowed down from the sample rate difference - - I noticed that you use AudioConverter api to adjust the sample rate of the input - would it also be possible to do it with the AUConverter audio unit in my graph? I'm not having much luck! Thanks!
Sure, although I didn't think that was necessary; doesn't the RIO unit do sample rate conversion for you?
A question to this sample rate conversion: In my app "Gender for iOS" I use 5 AUSampler. The samples are 44.1 mono CAF files set to different pan positions, should I set the sample rate in audio controller initialization to 44100 or leave it to the OS?
AEAudioController runs at 44100 by default.. I'm afraid I don't understand the question
So that means TAAE does the conversion, if iPhone 6S sticks to 48000?
Yup
Michael,
It took longer than I expected, but I finally got the new build up on TestFlight. Testing invites were just sent. The app is called Emitting. It's an audio broadcasting app that uses Bluetooth and p2p Wifi, with synchronized playback on all listeners. I couldn't have done it without TAAE!
Anyone else that would like to test, feel free to send email to beta at obeemobee dot com, and I'll send an invite ASAP!
Okay Michael, finally testing things (with 1.5.2) and I'm definitely having issues on my 6s where there are none on the 5s.
Both problems have to do with a frame/buffer mismatch in a processing block I think.
It appears using the new
AEAudioControllerOptionUseHardwareSampleRateflag fixes the issue, but is there anything I have to worry about when using this? I'm not well versed in audio sample rates and what not :PI take that back, my RMS/volume calculations are very different between the 5s and 6s.
My initial naive impression is that I'll need to scale down the dataPoints recorded on the 6s? Hoping there's a better way!
(The discrepancies are worst with very quiet sounds)
Hmm, 1.5.2 should handle the frame/buffer mismatch fine - what problems are you seeing specifically?
It seems like the 6s reports higher RMS/volumes than the 5s (we're talking at a near silence level). Is it possible this is just a hardware difference?
Yup, it is indeed possible. I assume you're using measurement mode?