Closing a window hangs for a second & causes pipewire to glitch

[Azorlogh]

Bevy version

Bevy v0.11.2

Relevant system information

Archlinux + pipewire 0.3.80 + x11

What you did

Close any bevy program's main window (if it includes the AudioPlugin).
Close any bevy program using Ctrl+C in the terminal (if it includes the AudioPlugin).

This happens whether or not bevy is actually playing any sound.

What went wrong

Expected: The window should close (almost) instantly without any audio issues.

Actual:
When I close the main window: it takes about ~1 second to close, and during that time, all of my desktop audio stutters (the last few milliseconds of audio repeat, causing audio popping).

When I Ctrl+C the terminal directly: the window closes almost instantly, and there is a short but loud popping sound.

It's not a major issue but it's a bit annoying as the audio glitching is often quite loud & uncomfortable, especially when it happens during a drum hit.

[A-Walrus]

I can partially reproduce this.
On Ctrl+C everything sounds fine, but when closing the main window I get a bit of audio buzzing (a lot less than 1 second)

Fedora 38 + pipewire 0.3.80 + wayland

[SolarLiner]

It looks like it is because of this:

bevy/crates/bevy_audio/src/audio_output.rs

Line 36 in c9e3285

std::mem::forget(stream);

The audio stream then never gets cleaned up properly, which means that the audio thread gets unloaded but the audio driver is not notified and continues requesting audio data.

On some platforms the audio driver automatically zeroes-out the audio buffer, meaning that the output is silent when that happens, but on others the drivers don't bother because the audio data is supposed to be overwritten anyways.

A proper solution would be to not use std::mem::forget and store the OutputStream, as a non-send resource.

[james7132]

Oh man that's going to be difficult to resolve without impacting the efforts for #9122 where we're trying to remove NonSend from the World entirely, and using SendWrapper is not going to be sufficient if we cannot control which thread the World is dropped on.

[SolarLiner]

@james7132 this is fixable though, by doing the same kind of wrapping that is done in kira for example, because it also has to wrap a cpal::Stream that is !Send + !Sync too.