I know working with audio over bluetooth causes a whole bunch of problems but I’ve been experiencing a recent issue that I wish could be resolved.
I just got a new iPad Pro and of course Apple got rid of the headphone jack forcing me to rely on bluetooth more and more. The problem is that opening Audulus with my active noise canceling headphones enables the mic input on the headphones and I don’t know how to turn it off. Now I hear room noise coming in while working and it’s a bit distracting. At first I thought this might just be an iOS issue but it doesn’t seem to happen in other apps.
Worst case I can use the dongle USBc to 3.5mm.
Sorry you’re having this issue! However this is a really weird one - are you saying if you start a blank, new patch and use your headphones, you will hear yourself in your headphones because the microphone on it is feeding back to them?
Correct. The headphone mic turns on (taking in audio form whatever my mic picks up around me) even when I tell the app not to allow mic access. I also notice that a red mic icon appears in the top right. I am attaching a screenshot.
Thanks for you assistance!
Just to clarify this happens immediately upon opening the app as well as in a project.
Does this only happen with Audulus or does it also happen with other music (or non-music) apps?
I have tested these apps:
Moog Model D
Moog Model 15
and various other non music apps.
So far I’ve only been able to create the issue in Audulus.
I’ve had the white cables of death mysteriously appear in patches that are otherwise fine, when when using AirPods with my 10.5" iPad Pro.
This is really odd - I wish I had bluetooth headphones myself to test. I’ll talk to Taylor about this one.
We’re still discussing how to solve this, but I want to check - have you tried turning your iPad all the way off and on again? Sometimes a good reset like that will do wonders.
I just restarted the iPad and removed the bluetooth headphones and reconnected them. It still seems to be having the same issue. (:
@FloatingSuburbia I saw your post about this yesterday, and I tested a few things with my 3 BT headsets (AirPods, Skullcandy Hesh 2, Beats Solo 3 wireless) and got the same result as you with each. I’m almost 100% sure the issue you’ve mentioned is related to something I tested and documented a while back. I just hadn’t noticed the input channel was actively passing audio before, as I live alone and my apartment is pretty quiet. You can view more info about my findings here.
There is not [currently] an iOS workaround, as you cannot choose another ‘input’ (as you want none active, without specifically requesting it with the mic or the ADC node) that will not take in sound, thereby changing the codec and disabling the mic in use, unfortunately.
On Mac you can select the internal microphone as the selected input source, changing the codec to a higher quality, as well as disabling the undesired input audio feed.
If you have the flow, I would absolutely recommend buying the desktop version, as well. I have both and I feel very strongly that it is worth the investment. It enables you to get a bigger view of what you’re working with, and you don’t have to keep zooming in to make connections and turn knobs etc while setting up and tuning, and zoom back out to get a better view of your patch as a whole. I build most of my patches on macOS and then use them on iOS later. @robertsyrett also mentioned reasons for this idea in a post not long ago.
If you only plan to work In iOS, then you should probably get a USB-C hub for your iPad. That will benefit you in many ways, as you can plug in headphones that way until this BT issue is fixed, and you will also have the ability to plug in a standard USB MIDI controller to your dock, which is really nice, imo.
Thanks for your reply and taking the time to test this with a variety of headphones. At least I know it’s not just my pair of headphones causing an issue.
I actually have purchased the desktop version and with your advice on workflow I will try working on desktop and using a patch on iOS later.
My last question to you would be… Why do you think this issue cannot be recreated in say Garageband on iOS if it still faces the same input source limitations?
Thanks for your help!
@FloatingSuburbia NP man, happy to be of service! I spent a while messing with GarageBand after discovering what I mentioned, and a little more today to refresh my memory, and I was able to ascertain that, however GarageBand is written, the reason why you don’t see this issue is because there is a fundamental difference in the way that iOS treats BT headphones when GB is open and in the foreground. The reason I mention foreground is because as soon as iOS backgrounds the app and Audulus is open, the default crappy 2-way audio profile returns.
iOS knows when you have BT headphones attached (this is why you get the warning about latency when you open GB while wearing BT headset or connected to a BT speaker), and something in their API seems to flip a switch to bypass the microphone on your wireless headset (I am certain that Apple is aware of the lower quality codec/dual-channel mono issue that results from using a microphone on a bluetooth headset), and the OS instead utilizes the microphone on the bottom of your device.
You can verify this yourself by opening the Garage Band app while your headphones are paired. Note the clarity you get compared with the audible input hum you hear when Audulus is running. You can then go to the audio loops section of the app, and start playing a loop or a few. Then, while that is running, click the microphone at the top of the screen. it will start the input while the loops are running. Run your finger over the mic of your BT headphones and watch the audio input level not move at all or maybe just slightly. Then run your finger along the bottom of your iPhone/iPad (maybe on the side, as I think there is also a mic on the side of the new iPad Pro) and watch the audio level on the input jump high on the meter.
I had a theory that if I opened Garage Band first, and used some other program as a bridge, it would keep Audulus respecting the BT audio setting of GB, which I specifically purchased Audiobus for the sake of testing. While Audiobus is another wonderful, very useful app for many other reasons, in this case, it was no dice, unfortunately.
Makes sense. I decided to pick up the USBc to 3.5mm cable for the iPad just to avoid Bluetooth. Maybe once iOS allows input source selecting I will try again. That combined with high latency just makes for a poor experience with BT headphones.
Thanks for all your help!