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

New issue

Open

opened 2026-09-28 18:00:57 +00:00 by backspace119 · 1 comment

backspace119 commented

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

Owner

Reported by a tester (Windows 11).

Symptom

No sound at all except the wind "whoosh" while flying. Every other sound is silent.

Setup

Windows 11.
Headphones on a 3.5 mm jack plugged into the motherboard (onboard audio).
Voicemeeter is installed. The user says the viewer's output device is set to the Windows default device, not a Voicemeeter device, so they don't think it's involved.
The latest Firestorm beta and the latest LL viewer have no sound at all for this user. So this is probably environmental (device / driver / Voicemeeter routing), not something Slipstream alone does. Slipstream is the only one producing any sound.

Why the wind still plays

Wind is synthesised by the viewer (LLWindGen, fed straight into the audio engine's stream). Everything else is decoded Ogg sound assets played through audio sources. So wind working while all assets are silent points at one of these rather than at the output device:

Sound asset fetch/decode: asset sounds never download or never finish decoding (cache, Vorbis decode, asset HTTP), so there is nothing to play. Wind needs no asset.
Source/channel allocation: channels fail to allocate or are all stolen.
Per-type gains: SFX / UI / ambient volume or mute (the master volume clearly isn't muted, since wind plays).

Next steps / need from the user

Slipstream.log from a session where they fly (wind plays) and trigger known sounds (UI clicks, a gesture sound, a teleport). Look for audio engine init (OpenAL device name, sample rate), audio decode or fetch errors, and "failed" lines around sounds.
Screenshot of Preferences > Sound & Media: every per-type slider and mute toggle.
Whether sounds work with Voicemeeter fully quit (not just unselected). Voicemeeter installs virtual devices and can take over the Windows default, so the device the viewer calls "default" may be a Voicemeeter input the user never hears.
Whether the Windows default output is the 3.5 mm onboard audio or a Voicemeeter virtual device at the moment they test, and the device's sample rate / format (Sound settings > device properties > Advanced), e.g. 24-bit/192 kHz or an unusual channel layout.
Whether they have the same problem with sound in other games/apps (sanity check).

Possibly related: #108 (degraded audio for one tester).

**Reported by a tester (Windows 11).** ## Symptom No sound at all except the wind "whoosh" while flying. Every other sound is silent. ## Setup - Windows 11. - Headphones on a 3.5 mm jack plugged into the motherboard (onboard audio). - **Voicemeeter** is installed. The user says the viewer's output device is set to the Windows default device, not a Voicemeeter device, so they don't think it's involved. - **The latest Firestorm beta and the latest LL viewer have no sound at all** for this user. So this is probably environmental (device / driver / Voicemeeter routing), not something Slipstream alone does. Slipstream is the only one producing any sound. ## Why the wind still plays Wind is synthesised by the viewer (LLWindGen, fed straight into the audio engine's stream). Everything else is decoded Ogg sound assets played through audio sources. So wind working while all assets are silent points at one of these rather than at the output device: - **Sound asset fetch/decode:** asset sounds never download or never finish decoding (cache, Vorbis decode, asset HTTP), so there is nothing to play. Wind needs no asset. - **Source/channel allocation:** channels fail to allocate or are all stolen. - **Per-type gains:** SFX / UI / ambient volume or mute (the master volume clearly isn't muted, since wind plays). ## Next steps / need from the user - `Slipstream.log` from a session where they fly (wind plays) and trigger known sounds (UI clicks, a gesture sound, a teleport). Look for audio engine init (OpenAL device name, sample rate), audio decode or fetch errors, and "failed" lines around sounds. - Screenshot of Preferences > Sound & Media: every per-type slider and mute toggle. - Whether sounds work with Voicemeeter fully quit (not just unselected). Voicemeeter installs virtual devices and can take over the Windows default, so the device the viewer calls "default" may be a Voicemeeter input the user never hears. - Whether the Windows default output is the 3.5 mm onboard audio or a Voicemeeter virtual device at the moment they test, and the device's sample rate / format (Sound settings > device properties > Advanced), e.g. 24-bit/192 kHz or an unusual channel layout. - Whether they have the same problem with sound in other games/apps (sanity check). Possibly related: #108 (degraded audio for one tester).

backspace119 commented

2026-09-28 18:17:11 +00:00

Author

Owner

Root cause found from the log. Every decoded sound fails to load:

LLAudioBufferOpenAL::loadWAV() Error loading C:\Users\[A COOL NAME]\AppData\Local\SlipstreamViewer\<id>.dsf I/O error

The file exists (the viewer's own UTF-8-aware isfile check passed), but ALUT's alutCreateBufferFromFile opens it with a narrow fopen(), which Windows interprets in the ANSI codepage, while our paths are UTF-8. A Windows profile name with non-ASCII characters (the tester's system is Portuguese, e.g. C:\Users\João) can't be opened, so no sound asset ever plays. The wind is synthesised in memory and needs no file, which is why it's the only thing audible.

The tester's other findings fit: other games are fine, the default device is the onboard speakers, and volumes are set correctly. Voicemeeter is not involved.

Fix (local, not pushed yet): read the decoded file through LLFile::getContents (wide-char API on Windows) and create the buffer from memory with alutCreateBufferFromFileImage.

The volume sliders were also checked: every slider and mute toggle is bound to an existing setting and is re-applied every frame (master = listener gain; SFX / UI / ambient = per-sound secondary gain; music = stream gain).

Workaround until the fix ships: none short of a profile path without accented characters.

Their Firestorm / LL viewer having no sound at all is likely a separate problem (different audio engines); not investigated.

**Root cause found from the log.** Every decoded sound fails to load: `LLAudioBufferOpenAL::loadWAV() Error loading C:\Users\[A COOL NAME]\AppData\Local\SlipstreamViewer\<id>.dsf I/O error` The file exists (the viewer's own UTF-8-aware `isfile` check passed), but ALUT's `alutCreateBufferFromFile` opens it with a narrow `fopen()`, which Windows interprets in the ANSI codepage, while our paths are UTF-8. A Windows profile name with non-ASCII characters (the tester's system is Portuguese, e.g. `C:\Users\João`) can't be opened, so no sound asset ever plays. The wind is synthesised in memory and needs no file, which is why it's the only thing audible. The tester's other findings fit: other games are fine, the default device is the onboard speakers, and volumes are set correctly. Voicemeeter is not involved. **Fix (local, not pushed yet):** read the decoded file through `LLFile::getContents` (wide-char API on Windows) and create the buffer from memory with `alutCreateBufferFromFileImage`. The volume sliders were also checked: every slider and mute toggle is bound to an existing setting and is re-applied every frame (master = listener gain; SFX / UI / ambient = per-sound secondary gain; music = stream gain). Workaround until the fix ships: none short of a profile path without accented characters. Their Firestorm / LL viewer having no sound at all is likely a separate problem (different audio engines); not investigated.

backspace119 referenced this issue from a commit

2026-09-28 20:10:33 +00:00

Audio: load decoded sounds through LLFile (non-ASCII Windows profiles had no sound)