In many cases, the Bluetooth audio system works to allow testers to experience audio testing with remote devices as if the devices were in-hand. However, Bluetooth audio is not an exact one-to-one replication of physical or wired audio due to the nature of Bluetooth programming; specifically, the different Bluetooth profiles can cause behavior that differs from the behavior seen with physical audio components. To assist you with your testing, we have compiled some common use cases you may encounter and suggested troubleshooting tips that may help you if your tests are not providing the expected results.
Getting Started: Use Cases/Case Studies
Below we've listed some common use cases, their interaction with Bluetooth audio profiles, and the likelihood the scenario will work in a HeadSpin testing environment. Users should map their use case to one of these common use cases if possible, to help with troubleshooting diagnosis. If your use case does not seem to compare with any of the use cases below, contact HeadSpin for assistance.
Use Case 1: Audio or video playback
You're using an app with audio where audio is played back to you but no microphone is needed (like Spotify, YouTube, Twitch, etc).
In this case, the application essentially tells the phone that it's streaming music and does not need microphone access. This causes the phone's OS to place the Bluetooth in A2DP mode (see our audio setup documentation for what that means technically).
The app and Bluetooth play high-quality audio.
This use case works as expected.
Use Case 2: Making a phone call
For context, let's imagine you are still listening to a song in an audio app from Use Case 1. You receive or make a phone call with the mobile device's built-in phone app or a third-party call app (for example Skype, Wickr, etc).
When the phone app answers, it tells the OS of the phone that a voice call is in progress and the microphone is needed. This causes the phone OS to switch the Bluetooth profile automatically to HSP to enable microphone usage.
Typically, your audio app’s content will auto-pause. If it doesn't, you will notice a decrease in audio quality due to the HSP profile having lower audio quality. On some older model phones you may experience a short audio drop during the profile switch.
Now the mobile device proceeds with audio in/out (speech and audio) working as expected.
When you hang up, the phone typically resumes the playback of audio media from your previously-running audio app (referenced above); if the OS detects no further voice call prompts, the microphone requirement is no longer needed, and Bluetooth will automatically return to A2DP profile for higher quality audio and no microphone access.
This is the most common Bluetooth headphone/microphone use case in the real world.
Because this is always the expected behavior for telephony/voice call apps in use with Bluetooth headsets, this works as with almost all applications. If a telephony app is not working as expected in our platform, it is likely a bug in the app’s design.
Use Case 3: Voice notes
In this scenario, the app in question is a stand-alone app designed to open and record a short audio clip, e.g., Voice Notes, SpeechTexter.
Most commonly when no active audio input/output combination is happening, the phone will keep the idle Bluetooth link in A2DP (for music playback).
Once the user clicks the "record note" button, a microphone is requested by the application. In order for the app to record through the Bluetooth microphone and not the physical microphone, the app has to request an audio stream/microphone from the OS in a way that triggers the profile switch to HSP so the Bluetooth microphone is active. Otherwise, if you request a microphone and Bluetooth is not in HSP profile, input will come from the physical microphone of the device by default. Depending on how the app has been designed, a number of outcomes are possible:
Outcome 1
If an app is written to request audio in such a way that causes the profile to switch automatically if Bluetooth is present, everything works as expected.
When the recording is done the phone will switch back to A2DP profile automatically as it idles or as other apps play audio.
Outcome 2
If an app is not written to initiate a profile switch to HSP, your audio note will be recorded using the physical microphone.
In the HeadSpin platform, using a device’s physical microphone will get some kind of result/recording; however, it will not be your audio note. What you will hear is background noise captured by the physical microphone of the device from the data center in which the device is located.
The phone will remain in A2DP profile throughout the tested behavior.
Outcome 3
If the developer programmed the app with a "record from Bluetooth" option in the settings, and this option is properly selected, then the profile will switch and everything will work as per Outcome 1. If unchecked it will work as in Outcome 2.
In many cases, if an app exhibits behavior like Outcome 2, this may be a bug where support for Bluetooth microphones has not been considered in the app’s code. Examples of real life scenarios where this lack of support may be detected include using the app on the phone in conjunction with a Bluetooth home speaker located in another room, in conjunction with a car’s Bluetooth audio system while the phone is in a bag or purse in the car, or the if the user has a high-quality profile Bluetooth boom mic/headset.
If you do not intend for your application to function as per Outcomes 1 or 3, then HeadSpin Bluetooth audio cannot fully support your audio use case. If you are testing with Android devices, we can provide a workaround that may mitigate or resolve your issue; for that workaround, please refer to our audio setup guide and review the Manual Profile Switching section.
If your test case requires injecting audio using the physical device microphone or testing the physical device speakers, please contact HeadSpin regarding our AVBox offering.
Workaround example:
Before starting your test, navigate to Bluetooth options in the HeadSpin Remote Control view and click "HSP" button. This forces the phone to switch to HSP profile, making the default mic the Bluetooth mic for all apps.
Begin recording in your voice notes app.
If your app selects the default mic, it will now work as expected and you will get audio from the Bluetooth link.
NOTE! If you're outputting audio at the same time (perhaps you play a jingle congratulating the user on recording their note) and you actively select high quality audio output stream you may no longer hear your output while in HSP mode, since the high quality Bluetooth link is inactive. To hear this output audio, you would need to switch back to A2DP profile. Typically if you're outputting to the default audio output this is not an issue.
Use Case 4: Smart assistant
Consider a scenario where the user wants to make a query with a major voice assistant, such as Google or Siri, often built-in on the mobile device’s OS
On hotwords: Many phones support hotword triggers, e.g., "OK, assistant" or "Hey, assistant". Hotword triggers frequently do not work with Bluetooth audio by design.
Some recent commercial Bluetooth headsets do support this, but please note that this hotword detection occurs onboard inside the headset. When using these devices you are not testing the hotword detection of the phone, but of the headset. HeadSpin does not yet support this functionality.
In some cases it may appear that your headset works with hotword triggers at home (local testing). You can say "Hey assistant" while paired to your Bluetooth headset and it works. Most of the time, this is because your physical phone microphone is nearby and can still pick up your voice. The hotword trigger is, therefore, still being received and processed via the physical microphone, not through Bluetooth.
The user triggers a voice query by clicking a button to start the query.
Outcome 1: As in Use Case 3, if the assistant app is programmed to request the Bluetooth input and trigger a profile switch when available (or via some setting), then this will work as expected. Your query is captured and everything works!
Outcome 2: Otherwise (again, as in Use Case 3), the physical microphone is used and the voice assistant receives audio from the data center, meaning you may see some recording activity occurring but it is not the audio you are sending. This is quite common with smart assistants.
Our previously mentioned Android workaround may apply, but this is a best effort workaround and is not guaranteed to resolve all issues. The same caveats regarding output as listed above will apply. Be sure to click the HSP button before your query.
Voice assistants are an example of apps that deliberately choose not to use the Bluetooth input. Many flagship devices (e.g., Google’s suite of devices) now include physical microphone arrays to do directional recording and provide better audio capture for assistant queries. The manufacturers prefer to use this hardware over Bluetooth. In some cases these manufacturers partner with third-party Bluetooth manufacturers to certify Bluetooth hardware that will work with their smart assistant and only use Bluetooth with those devices. If testing at home with commercial equipment, it's possible you may be using a certified device that the mobile device will prioritize over physical audio; this would be a deceptive test.
Often, users see the active speaker/microphone in our UI and assume this indicates that all audio components are working.
These icons actually mean that audio is being recorded locally and is sent to the HeadSpin platform from the physical device. Depending on how the app and OS are interacting, the audio stream may not be reaching the app properly. In these cases, either Bluetooth is not connected, or some of the Bluetooth profile issues described here are present. For troubleshooting tips regarding these issues, see below.
Troubleshooting: Microphone and Bluetooth Profiles
If you are experiencing unexpected behavior with the microphone while testing, review the following:
1. Is the app in question expected to work with Bluetooth hardware, such as Bluetooth headsets? As described above, applications that support Bluetooth headsets should work normally with HeadSpin devices. If they do not, there is likely a bug in the application's handling of Bluetooth profile switching.
If you are the developer, refer to our audio setup guide to try resolving the issue.
If you are not the app developer, we recommend filing a bug report with the app.
Note: When comparing with consumer headphones, place your phone in a different room from the Bluetooth headphones to check if Bluetooth microphone support is working. Many apps accidentally rely on the physical microphone in the phone to capture audio while using Bluetooth headphones, which can be misleading.
1. If the app doesn't support profile switching or you need to test despite a bug, we may be able to provide a workaround. A third party application can be used to force the phone to switch profiles (see our Bluetooth Setup guide in the Manual Profile Switching section). In some cases, this may allow your tests to work as expected; however, this is app-dependent, and in many cases it will only enable microphone input OR audio output but not both simultaneously. In some cases automation of this workaround may be possible. Please contact support for more details.
HeadSpin's platform does not support wired audio testing, although we do provide other products for physical audio capture and playback. Please reach out to HeadSpin for more details regarding our AVBox audio testing solution.
Troubleshooting: App Support and Bluetooth Profiles
Generally speaking, apps have to be capable of handling profile switching - as with the Use Cases 2 and 4 described above, users often need to be able to switch quickly between microphone use and high quality audio streaming.
However, some apps do not properly support Bluetooth profile switching, and some device models and/or mobile OS versions may behave differently than expected; because of these scenarios, apps may work on some devices and not others. When this happens, we recommend double-checking the following:
On Android devices, applications intending to record audio should refer to AudioManager.startBluetoothSco() and ensure that their audio input and output are using the correct audio stream, e.g., AudioManager.STREAM_VOICE_CALL or something similar.
On iOS devices, applications must allowBluetooth and select the appropriate audio input/output for audio routing.
