Search Issue Tracker
By Design
Votes
0
Found in
2018.4
2019.4
2019.4.4f1
2020.2
2021.1
2021.2
Issue ID
1311343
Regression
No
[Linux] Unity picks up system sounds with Microphone.Start when no microphone is connected
Reproduction steps:
1. Download and open the attached project: "LinuxMicrophoneTest.zip"
2. Enter Play Mode
3. Play a system sound e.g. raise the volume
Expected result: You can only hear the system sound
Actual result: You can hear the system sound and Unity playing it back as well
Reproducible with: 2018.4.32f1, 2019.4.20f1, 2020.2.5f1, 2021.1.0b7, 2021.2.0a4
Notes:
- Tested on Ubuntu 18.04
- Reproducible in Editor and Player
- Ensure no microphone is connected to the system when reproducing the issue
- Does not reproduce on 11.1 or 10.15.7 macOS
- Unable to test on Windows due to Windows not asking for microphone permissions or the Editor freezing upon entering Play mode
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- “[Worker0] Could not generate preview image“ error when opening macOS native plugin in the Inspector with Architecture to build for set to ARM 64-bit
- [iOS] Application.absoluteURL is empty on Awake/Start when opening via deep link with Splash Screen disabled
- Crash on MemoryManager::Deallocate when rapidly calling Addressables.LoadAssetAsync
- Crash on physx::shdfnd::atomicIncrement when adjusting values on a character controller component after entering Play mode in Prefab edit mode
- [Rendering Debugger] [NewInputSystem] Debug Overlays in Play mode throws InvalidOperationException when using New Input System
Resolution Note (2021.2.X):
We have to close this issue and call it "By Design", even though that is far from what is desired. We were hoping to address the problem by making changes to FMOD and prevent it from calling down to PulseAudio when we can figure out that there is actually no microphone attached. However, it seems that the problem PulseAudio had to distinguish whether a mike was attached or not were very real, and cause by how devices are reported by Linux itself. In FMOD we therefore hit the same wall. I'm going to leave a request on the PulseAudio forums to look into this, but I doubt whether they can do much given all this. In fact, I see various related complaints there already, some fairly old. The only way around this problem for now would be to have a high-level toggle that prevents calling sound code paths when a microphone is (known to the human) not attached.