Bad sound quality when upgrading to Rust 1.45

[Rua]

I updated my toolchain to use Rust 1.45, this has broken the audio playback using Rodio 0.11.0. The sound comes out as somewhat muffled, like it was low-pass filtered. I can restore the correct audio by downgrading Rust back to 1.44.1, so clearly there is something going on with changes made in the compiler and how they interact with Rodio. Perhaps the changes in float-to-integer casts are to blame.

I've attached a sound recording for comparison. First, two sound effects are heard from Rust 1.45, then the same two effects in Rust 1.44.1. (Yes, these are old Doom sound effects, if anyone is wondering :) )

brokensound.ogg.zip

To play this audio, I use a custom Source that reads its samples from an Arc<[i16]>, so that I can keep the buffer around after playing it. This is then wrapped in the ChannelVolume, Done and SamplesConverter sources, sent to another thread (to avoid the COM initialisation bug on Windows), where it is then played via rodio::play_raw.

[est31]

Hi! interesting report. You could try to narrow it down by bisecting the rustc: https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md

Then we'd know what to look for.

[Rua]

Here's the result I got from it:

searched nightlies: from nightly-2020-05-01 to nightly-2020-07-20
regressed nightly: nightly-2020-05-20
searched commits: from rust-lang/rust@d887886 to rust-lang/rust@3a7dfda
regressed commit: rust-lang/rust@672b272

[Rua]

I just checked the output of the Source that's being fed to rodio::play_raw in both versions. It gives the exact same stream of f32s. So it's definitely not a problem in my side of the code, something is going wrong after Rodio gets the Source.

[est31]

It's probably due to some UB caused by the tiny vecs change. Interesting...

[Rua]

I've confirmed the bug on my laptop as well. The project in question exhibiting the bug is https://github.com/Rua/ferret.

[nbraud]

For what it's worth, looking at the code there's nothing in rodio that seems suspect, but cpal has a lot of unsafety in the ALSA backend ( both src/alsa/ and alsa-sys/ ).

It would be interesting to check on the other cpal backends, to confirm whether the issue is specific to ALSA,

[est31]

@Rua which OS are you using? Windows?

Also it would be great to have a self contained example, i.e. one that doesn't need quake wad files. Do the rodio examples work for you?

[nbraud]

@Rua which OS are you using? Windows?

Rua had the issue on Linux (Mint, IIRC), and I reproduced it on Debian.

[Rua]

I cloned a copy of Rodio 0.11.0 and modified it so that in audio_callback, the samples being received from the mixer are printed before they are written to cpal's buffer. I did this for both Rust 1.44.1 ("good") and Rust 1.45 ("bad"), and here are the results:

good.txt bad.txt (48 kHz stereo)

Clearly, the two files are not the same. So it appears that the fault is somewhere between rodio::play_raw and audio_callback.

[Rua]

I've narrowed the problem down further to SampleRateConverter. If I remove that from the processing pipeline, the samples in the two versions become identical again.

[Rua]

I found the problem! In SampleRateConverter, various bits of code rely on the return value of capacity(). So in SampleRateConverter::new I printed the capacity of current_frame, next_frame and output_buffer:
Rust 1.41.1 output: 2 2 1
Rust 1.45 output: 4 4 1
So this is how that commit in Rust caused problems. Rodio was relying on the capacity being a certain value, and it changed. Presumably, the code should be modified so it uses a measure other than the capacity?

[est31]

Nice, a logic bug... Yeah it should be changed to have outputs independent of the capacity.

[Rua]

Has any work been done on this? I am thinking how I could fix it myself, but I don't know how the code is supposed to work or why it's using the capacity in the first place.

[Rua]

It appears that @tomaka was the one who originally wrote the code, maybe he has some insight?