I think I see what's going on. We have some logic that uses the hands-free device on the output side if we find that the microphone on the same physical device has been picked for input (which isn't your case). If I recall correctly, this is both to have lower round-trip latency, but also to avoid issue on some devices, that had all sorts of errors when activating the microphone but also attempting to use the A2DP device at the same time (however it's been some time since then, my recollections might be incorrect). I think in this particular case of a Bluetooth headset having a mic, that is **not** used, and two output devices (handsfree and A2DP), and also having another mic available (that is used), there's a bug in which our audio IO layer, where we fail to check what the device on the input side is in use, and switches the output side to the handsfree device under the hood. It might be related to which device is set as a default in the Windows settings (`mmcpl.cfg`). I've ordered some hardware to reproduce this, as I've recently switched my Windows system from a laptop (that had Bluetooth hardware) to a much more powerful desktop workstation (that doesn't have Bluetooth or wifi).
Bug 1888896 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think I see what's going on. We have some logic that uses the hands-free device on the output side if we find that the microphone on the same physical device has been picked for input (which isn't your case). If I recall correctly, this is both to have lower round-trip latency, but also to avoid issue on some devices, that had all sorts of errors when activating the microphone but also attempting to use the A2DP device at the same time (however it's been some time since then, my recollections might be incorrect). I think in this particular case of a Bluetooth headset having a mic, that is **not** used, and two output devices (handsfree and A2DP), and also having another mic available (that is used), there's a bug in which our audio IO layer, where we fail to check what the device on the input side is in use, and switches the output side to the handsfree device under the hood. It might be related to which device is set as a default in the Windows settings (`mmsys.cpl`). I've ordered some hardware to reproduce this, as I've recently switched my Windows system from a laptop (that had Bluetooth hardware) to a much more powerful desktop workstation (that doesn't have Bluetooth or wifi).