ValveSoftware / ValveSoftware/Proton
Microphone interface detected, but microphone not captured, by games when using ALSA
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 32.8k
- Forks
- 1.6k
- PR merge metrics
- PR metrics pending
Description
Background: using an .asoundrc file on an ALSA-only system to specify a USB microphone interface. Microphone input works correctly system-wide in Linux, Steam voice calls within the Linux client, audio recording software, OBS, etc.
The ALSA config file or output of alsactl can be attached if necessary. The config file adds the microphone, duplex, mixer control, loopback support, and the dsnoop plugin, which allows multiple programs to capture audio simultaneously.
System/kernel: 6.2.2-arch1-1
Proton version: Experimental, 7.0-6, all previous versions
Steps taken:
- Allow a wine prefix to be created for the appid in question.
- Use winetricks in the prefix with the verb
sound=alsato update the registry. - Open winecfg, navigate to Audio tab, and open the dropdown dialog for
Voice input device - Verify that the microphone interface is present (in this case, "Scarlett Solo USB") and select it from the dropdown
- Launch the game with Proton and attempt to use voice input, either via in-game microphone tests or communication with players
Microphone input is never passed through to the game, even in games reported elsewhere as having microphone support in Proton.
A sample of games tested, alpha order:
- Dark and Darker Demo (2258570)
- Dark and Darker Playtest (2078890)
- Day of Infamy (447820)
- DayZ (221100)
- Deep Rock Galactic (548430)
- HELLDIVERS™ (394510)
- Treason (1786950)
- Unfortunate Spacemen (408900) (possibly related to #4095)
- We Were Here (582500)
I was unable to get microphone input in any of these games (with one caveat for Day of Infamy below), although the microphone interface itself was detected in all of them.
As a control, I tested adding the Windows version of Audacity as a Non-Steam Game and forcing Proton (Experimental, 7.0-6, other versions) as a compatibility tool using the same steps above (set input device in winecfg, etc.), then launched it and selected the microphone interface within Audacity and recorded a sound sample and played it back. This DID capture audio despite the application running inside Proton.
My initial surmises were that there are additional layers of middleware present in games, whereas Audacity captured the raw microphone input. However, two other interesting data points follow:
- Day of Infamy uses the Source engine and reverts to default Source menus under the hood for some options. When opening the microphone configuration through Day of Infamy's reskinned settings frontend, it triggers a vanilla Source dialog for microphone test/input selection, the same seen in games like Half-Life and Counter-Strike 1.6. Within this menu, the interface was also detected and selectable, and the microphone test DID capture sound. However, this did not carry over once within the game.
- Treason uses the Source engine and does not reskin the menus, using them by default. When setting voice options, it opens the same menu as item 1 above, but in this case, the microphone interface was detected, but audio was not captured by the microphone test.
Even allowing for different audio capture middleware (some games use, e.g., Vivox), the sample size of games tested is quite large, yet I was unable to get it working in any of them, except for the Audacity control test. I would like to know what is the missing step here or what can be done to extend support, since for all intents and purposes the interface and the audio do seem to be reaching inside the Wine prefix.
My last guess here would be that this is adjacent to https://github.com/ValveSoftware/steam-runtime/issues/344, insofar as Proton runs in a container, and that the dmix/dsnoop plugins maybe cannot penetrate the container correctly, so if you advise testing with a stripped-down .asoundrc, I can do that as well.
However, I maintain that, per the tests above, the interface and audio are reaching most, if not all games, already. And needless to say, audio playback itself works fine in every game despite this configuration.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Begin with the reported .asoundrc setup and the winecfg Audio tab, using the sound=alsa winetricks step as the reproduction entry point. Compare microphone capture in the listed games with the Windows Audacity control and check the proposed Proton container/dmix/dsnoop angle. Done means identifying the missing support or configuration step that makes input reach a Proton game.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- audio-video-rtc
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100