osu!lazer segfaults with non-default audio latency testing setting when it does too many audio things?

[JacksonChen666]

So ppy/osu-framework#6724 made it into a release. I am testing it.

So far it has reduced latency, but not without audio crackling compared to the default setting. (-128 has been the lowest with least instability, but there's crackling sometimes, but crackling also happens outside of osu!lazer, so... that's not your problem)

Sometimes I've had osu!lazer crash when it seems to try to do many audio things at once before. Couldn't be bothered to attempt to reproduce.

Then I accidentally found a really easy way to reproduce those crashes: Switching mods from Double Time to Nightcore. Back and forth, constantly. Here's a video demonstration of 4 segfaults in a row (with the 4th letting the frame rate stabilize):

2026-06-05.07-26-51-cut.mp4

^{(The first segfault in the terminal was not related to audio stuff. It was osu!lazer segfaulting after I killed Fcitx5 because mod shortcuts didn't work when I had Fcitx5 and used Xwayland instead of Wayland for osu!lazer. For some reason.)}

Further testing with OSU_TEMP_TESTING_BASS_CONFIG_DEV_PERIOD:

• -128 (used in video): Crashes
• -441 or 10 (same as osu!lazer default without using this setting): Works fine, no crashes
• Any number divisible by 10 (so 20, 30, 40, and even 100 (after raising PipeWire max quant limits)): Works fine, no crashes
• 25: Crashes
• 5: Crashes

---

Another way I found is the Adaptive Speed mod. It takes a very variable amount of time to trigger it (I got it once within 10 seconds, then a second one in 2 minutes), but it will eventually trigger it, meaning that in general the Adaptive Speed mod is unplayable if you have a custom latency whatever thingy thing in use. (I don't have a video for this, as the mod switching is quicker to do)

---

Yet another way is spinners. Variable, but not good either.

---

• osu!lazer 2026.518.0-lazer (installed into /opt/osu-lazer-bin-2026.518.0/ via unpacking the AppImage into it as-is)
  • compressed-logs.zip
  • Command: OSU_TEMP_TESTING_BASS_CONFIG_DEV_PERIOD=-128 OSU_EXTERNAL_UPDATE_PROVIDER='1' OSU_EXTERNAL_UPDATE_STREAM='Lazer' /opt/osu-lazer-bin-2026.518.0/osu\!
  • Coredumps: DM me directly for a link (it probably contains sensitive information & is 611 MiB)
• pipewire 1.6.4 (I doubt it's version specific though)
• niri 26.04 (this is the wayland compositor and probably not relevant)

Coredumps self note

TIME                             PID  UID  GID SIG     COREFILE EXE                                  SIZE
Fri 2026-06-05 07:28:24 CEST 3880119 1000 1000 SIGSEGV present  /opt/osu-lazer-bin-2026.518.0/osu! 160.6M
Fri 2026-06-05 07:28:40 CEST 3880835 1000 1000 SIGSEGV present  /opt/osu-lazer-bin-2026.518.0/osu! 145.2M
Fri 2026-06-05 07:29:03 CEST 3881890 1000 1000 SIGSEGV present  /opt/osu-lazer-bin-2026.518.0/osu! 143.9M
Fri 2026-06-05 07:29:21 CEST 3882620 1000 1000 SIGSEGV present  /opt/osu-lazer-bin-2026.518.0/osu! 161.1M

[peppy]

Looks like you’re trying to get osu! running on Linux. We don’t have the ability to support it as well as one may hope right now because of the wide range of distributions, libraries, and hardware setups.

As such our current policy is to direct users to this linux friendly discord.

They’re familiar with common workarounds and can guide you through distro‑specific steps. If you uncover anything we should know, feel free to report back so we can improve our guidance.

[JacksonChen666]

So I went there and asked, and @GGchung69 (and 2 other people since then) was able to reproduce the DT/NC repeated switching causing a segfault with OSU_TEMP_TESTING_BASS_CONFIG_DEV_PERIOD set (to -59, weird value but ok). This means that this reproducible issue probably isn't specific to my setup.

At this point, if there has been no attempt to reproduce this issue on your side (using any Linux), I'd suggest at least giving the DT/NC repeated switching with OSU_TEMP_TESTING_BASS_CONFIG_DEV_PERIOD set a try to anyone in the team.

[NelloKudo]

Tried looking into the issue and this doesn't really seem like an osu! issue but a BASS bug to me.

With DeviceBufferLength = 1 that tiny buffer seems fine on its own, but once a BASS_FX_TempoCreate stream is in the mixer (so daycore/nightcore is enabled) and the tempo is changed at runtime, SoundTouch briefly produces samples too slowly and returns fewer than the mixer asked for. Bass' mixer seems to mishandle the short read though and that's where it crashes.

From the coredump, the crash is at libbassmix.so + 0x5f74, which is rep movsb (%rsi),(%rdi)

imul  %edx,%eax              ;   eax = index * channels  (-7 frames * 2ch = -14)
lea   0x0(%rbp,%rax,4),%rsi  ;   (uses full 64-bit rax)
rep   movsb (%rsi),(%rdi)    ;

Registers are:

rax = 0x00000000fffffff2  ; the offset which should be -14
rbp = 0x7f24657eda50      ; source buffer base
rsi = 0x7f28657eda18      ; = rbp + rax*4 (~16 GiB)
rdi = 0x7f24b43ffda8      ; dest buffer (valid)
rcx = 0x80                ; 128 bytes to copy

So on the short read the offset comes out as -14, which is correct as a signed 32-bit int, but the lea builds the source pointer using the full 64-bit rax, and since eax was written by a 32-bit op the upper half is zeroed instead of sign-extended. So -14 reads as ~4 billion, that multiplied by 4 bytes makes it land like 16GiB past the buffer (which is of course unmapped) and the rep movsb ends up faulting.

The real fix would be needed in BASS handling the short read, if we want to keep using a tiny buffer for latency.