Audio sounds degraded ("like really bad headphones") for one tester #108

New issue

Open

opened 2026-09-27 16:43:35 +00:00 by backspace119 · 1 comment

backspace119 commented

2026-09-27 16:43:35 +00:00

Owner

A tester reports audio that sounds "weird", as if they "had really bad headphones" (muffled / tinny / low quality). No one else has reported it so far.

Known so far

Single report. Platform, build, and which sounds are affected are unknown.
It's not yet known whether it affects in-world sounds, UI sounds, streaming music (parcel audio / media), or voice.

Information to collect

Platform (Windows / Linux), release tag, and output device (e.g. USB/Bluetooth headset, speakers). Also the sample rate the device is set to.
Which sounds are affected: in-world object sounds, UI clicks, parcel music stream, media (web/video), or voice.
Whether the same setup sounds normal in another viewer (e.g. Firestorm / the official viewer).
Alchemy.log from an affected session (the audio engine init lines log the OpenAL device and output rate).

Candidates

OpenAL output mixing at a sample rate different from the device's (resampling artifacts), or a mono/HRTF path: OpenAL Soft HRTF on stereo headphones can sound "phasey" or muffled.
Bluetooth headsets switching to the hands-free (HFP/HSP) profile when the voice capture device is opened. That gives classic "bad headset" sound, and it can be triggered by voice (Vivox / WebRTC) initializing the microphone. It's a common cause on Windows.
Windows build specifics: the bundled OpenAL32/alut, and the fact that we build with /fp:fast.

A tester reports audio that sounds "weird", as if they "had really bad headphones" (muffled / tinny / low quality). No one else has reported it so far. ### Known so far - Single report. Platform, build, and which sounds are affected are unknown. - It's not yet known whether it affects in-world sounds, UI sounds, streaming music (parcel audio / media), or voice. ### Information to collect - Platform (Windows / Linux), release tag, and output device (e.g. USB/Bluetooth headset, speakers). Also the sample rate the device is set to. - Which sounds are affected: in-world object sounds, UI clicks, parcel music stream, media (web/video), or voice. - Whether the same setup sounds normal in another viewer (e.g. Firestorm / the official viewer). - `Alchemy.log` from an affected session (the audio engine init lines log the OpenAL device and output rate). ### Candidates - OpenAL output mixing at a sample rate different from the device's (resampling artifacts), or a mono/HRTF path: OpenAL Soft HRTF on stereo headphones can sound "phasey" or muffled. - Bluetooth headsets switching to the hands-free (HFP/HSP) profile when the voice capture device is opened. That gives classic "bad headset" sound, and it can be triggered by voice (Vivox / WebRTC) initializing the microphone. It's a common cause on Windows. - Windows build specifics: the bundled OpenAL32/alut, and the fact that we build with `/fp:fast`.

backspace119 commented

2026-09-27 16:46:48 +00:00

Author

Owner

Tester setup: wired 3.5 mm headphones in the front-panel jack, Gigabyte B550 AORUS ELITE V2 (Realtek onboard codec), Windows 11.

That rules out the Bluetooth hands-free-profile theory.

Leading hypothesis: OpenAL Soft auto-HRTF. Our Windows build uses OpenAL (FMOD is off), opened with alutInit(NULL, NULL), which gives the default device and context attributes. OpenAL Soft's default is hrtf = auto: it enables HRTF binaural rendering whenever the output endpoint reports itself as headphones. Realtek front-panel jacks typically report exactly that. Generic-dataset HRTF often sounds muffled, "phasey", or "like bad headphones" to people it doesn't fit. Official/Firestorm Windows builds use FMOD, so users don't hear this there. Linux/PipeWire setups rarely report a headphone form factor, which fits a single Windows report.

Quick test for the tester (no rebuild): create a text file %APPDATA%\alsoft.ini containing

[general]
hrtf = false

then restart the viewer. If the audio becomes normal, it's HRTF.

Proposed fix: create the ALC context ourselves (alcOpenDevice + alcCreateContext with ALC_HRTF_SOFT = ALC_FALSE by default), with a preference to enable it. Also log the ALC_HRTF_STATUS_SOFT and output frequency in Alchemy.log.

Tester setup: **wired 3.5 mm headphones in the front-panel jack**, Gigabyte B550 AORUS ELITE V2 (Realtek onboard codec), **Windows 11**. That rules out the Bluetooth hands-free-profile theory. **Leading hypothesis: OpenAL Soft auto-HRTF.** Our Windows build uses OpenAL (FMOD is off), opened with `alutInit(NULL, NULL)`, which gives the default device and context attributes. OpenAL Soft's default is `hrtf = auto`: it enables HRTF binaural rendering whenever the output endpoint reports itself as *headphones*. Realtek front-panel jacks typically report exactly that. Generic-dataset HRTF often sounds muffled, "phasey", or "like bad headphones" to people it doesn't fit. Official/Firestorm Windows builds use FMOD, so users don't hear this there. Linux/PipeWire setups rarely report a headphone form factor, which fits a single Windows report. **Quick test for the tester** (no rebuild): create a text file `%APPDATA%\alsoft.ini` containing ``` [general] hrtf = false ``` then restart the viewer. If the audio becomes normal, it's HRTF. **Proposed fix:** create the ALC context ourselves (`alcOpenDevice` + `alcCreateContext` with `ALC_HRTF_SOFT = ALC_FALSE` by default), with a preference to enable it. Also log the ALC_HRTF_STATUS_SOFT and output frequency in `Alchemy.log`.

backspace119 referenced this issue from a commit

2026-09-27 16:58:15 +00:00

OpenAL: own the device/context, HRTF opt-in (AudioOpenALHRTF, default off)

backspace119 referenced this issue

2026-09-28 18:00:57 +00:00

Audio: no sound except the flying wind (Windows 11, onboard 3.5 mm, Voicemeeter installed) #146