HRTF stuck on even when directional audio is set to off in update 1.20.2

same happened to me on an older version sounds are fine but not on 1.20.2

it might be a feature

cannot reproduce

Yup, audio sounds trash in 1.20.2

Can reproduce. The workaround works too.

Can reproduce

Interestingly enough, I have experienced this issue with both HRTF being stuck on and HRTF being stuck off, depending on where I run the game (in a third party launcher HRTF is stuck on, but in FabricMC's Loom dev environment HRTF is stuck off). After some investigation, I think I found the cause of the issue.

Code Analysis

In com.mojang.blaze3d.audio.Library, the init method calls the setHrtf method to set directional audio on or off.

// Inside: public void init(String audioDevice, boolean hrtfEnabled)

this.setHrtf(deviceCapabilities.ALC_SOFT_HRTF && hrtfEnabled);

Inside the setHrtf method, the alcResetDeviceSOFT method is called on the current audio device with two attributes. The ALC_HRTF_SOFT attribute sets HRTF on or off, and the ALC_HRTF_ID_SOFT attribute sets the index of the desired HRTF file, which is currently hardcoded to 0.

// Inside: privatevoid setHrtf(boolean hrtfEnabled)

var attributes = memory.callocInt(10)
        .put(SOFTHRTF.ALC_HRTF_SOFT).put(hrtfEnabled ? ALC10.ALC_TRUE : ALC10.ALC_FALSE)
        .put(SOFTHRTF.ALC_HRTF_ID_SOFT).put(0)
        .put(0).flip();
if (!SOFTHRTF.alcResetDeviceSOFT(this.currentDevice, attributes)) {
    // ...
}

According to this text document, the alcResetDeviceSOFT method should be used for resetting an audio device's attributes so that they may be changed during runtime.

While the code above functions correctly in resetting an audio device's attributes with new values, its effect is imminently overridden by the creation of a new audio device context, which replaces the current audio device's attributes.

// Inside: public void init(String audioDevice, boolean hrtfEnabled)

// Attributes enabling/disabling HRTF are set here...
this.setHrtf(deviceCapabilities.ALC_SOFT_HRTF && hrtfEnabled);
try (var memory = MemoryStack.stackPush()) {
    var attributes = memoryStack.callocInt(3)
            .put(SOFTOutputLimiter.ALC_OUTPUT_LIMITER_SOFT).put(ALC10.ALC_TRUE)
            .put(0).flip();
    // ...but are immediately overriden here.
    this.context = ALC10.alcCreateContext(this.currentDevice, attributes);
}

Before Minecraft snapshot 23w31a, this was not an issue as no attributes were given in the creation of a new context. However, in 23w31a, the ALC_OUTPUT_LIMITER_SOFT attribute was added to the context creation, nullifying the effect of the setHrtf method from before.

Probably the most straightforward way to fix this is to move the calling of setHrtf after the creation of the audio device's context.

However, this creates the opposite problem where the ALC_OUTPUT_LIMITER_SOFT attribute is nullified by calling setHrtf. So, it may be simpler to just set all attributes at once.

// Inside: public void init(String audioDevice, boolean hrtfEnabled)

// Deleted:
// this.setHrtf(deviceCapabilities.ALC_SOFT_HRTF && hrtfEnabled);

try (var memory = MemoryStack.stackPush()) {
    // int allocation increased from 3 to 7, as there could be 4 additional int values
    var attributes = memory.callocInt(7);

    attributes.put(SOFTOutputLimiter.ALC_OUTPUT_LIMITER_SOFT).put(ALC10.ALC_TRUE);

    // Set attributes enabling or disabling HRTF during context creation
    if (ALC10.alcGetInteger(this.currentDevice, SOFTHRTF.ALC_NUM_HRTF_SPECIFIERS_SOFT) > 0) {
        attributes.put(SOFTHRTF.ALC_HRTF_SOFT).put(
                deviceCapabilities.ALC_SOFT_HRTF && hrtfEnabled ?
                ALC10.ALC_TRUE : ALC10.ALC_FALSE);
        attributes.put(SOFTHRTF.ALC_HRTF_ID_SOFT).put(0);
    }

    this.context = ALC10.alcCreateContext(this.currentDevice, attributes.put(0));
}

I have implemented these changes in a FabricMC mod for testing purposes, and it seems to have fixed the issue for me. The source code for the mod can be accessed here: https://github.com/bytzo/mc-265514. Obligatory warning to proceed with caution: while I can trust myself, you can't trust me, so please audit the code yourself before compiling or running.

Can reproduce on Linux, both in Debian 12 and OpenSUSE Tumbleweed, installed in 2 different computers.

By editing /etc/openal/alsoft.conf on my Debian 12 computer to include the line drivers = alsa, audio works correctly up to Minecraft 1.20.1. In versions 1.20.2 and above, there is no audio output other than the narrator voice.

By editing the same file but adding drivers = pulse instead, I can hear the audio from every version, including 1.20.2 and beyond, but its quality is really low, like if it came from inside a tin can.

In both computers I'm using Pipewire, not PulseAudio, in case that has something to do with the issue.

I have compiled the Fabric mod provided by Bytzo in its comment to this issue and it has fixed the audio problems for me, both in Minecraft 1.20.2 and in the latest snapshot.

Thanks Bytzo for providing a workaround!

Can confirm this issue is still present in 1.21 Release Candidate 1

It used to be possible to specify a different version of the OpenAL library in a Java argument, but it doesn't seem to work anymore. It just crashes the game.

In the example below, the OpenAL dll version 3.3.1 placed directly under .minecraft is specified, but the game crashes just as if nothing was specified. It seems to have been fixed.

It was my mistake. The crash was caused by a space before the path specification. I've written it below so that no one else makes the same mistake.

People who are experiencing this bug probably had it working fine in 1.20.1 or earlier, so specifying the OpenAL library used in 1.20.1 may solve the problem.

I had the opposite problem of not being able to turn on Directional Audio, but this solved it.

Once you start up with 1.20.1, a folder named "3.3.1" should be created in ".minecraft\libraries\org\lwjgl\lwjgl-openal". Open or unzip "lwjgl-openal-3.3.1-natives-windows.jar" in that folder using the appropriate method (such as using 7zip), and copy "OpenAL.dll" from "lwjgl-openal-3.3.1-natives-windows.jar\windows\x64\org\lwjgl\openal" and place it wherever you like, such as in ".minecraft".

After that, please specify the following in the JVM arguments section of the launcher startup settings. Change the username etc. to suit your environment.

// Not work
-Dorg.lwjgl.openal.libname= "C:\Users\yourname\AppData\Roaming\.minecraft\OpenAL.dll" 


// Work
-Dorg.lwjgl.openal.libname="C:\Users\yourname\AppData\Roaming\.minecraft\OpenAL.dll"