Audio files with mismatched characteristics play incorrectly

[Fussmatte]

There appears to be some issues with certain custom audio playback in latest builds. I have a custom vvvvvvmusic.vvv file for my level, with two tracks. The first track is two seconds long, and the second one is 2:43.

If I start my level and play the first track followed by the second, the latter will play choppily and at a very low pitch/speed. If instead I play the second followed by the first, the first one will play choppily and at a high pitch/speed. This clip shows both happening (forgive the silly level content):

https://user-images.githubusercontent.com/44736084/179419073-74d670f0-52a2-4b38-afe1-28a7635fa43b.mp4

@Dav999-v, using the same vvvvvvmusic.vvv file that I sent him, also demonstrates the second instance happening, though a bit differently with very loud intermittent noises, possibly due to using the Linux build:

(VOLUME WARNING)

https://user-images.githubusercontent.com/44736084/179419133-71df0cd6-6c77-4b02-a1bc-56645623ddcf.mp4

This may be related to FAudio changes, as suggested by Dav.

Both audio tracks are Vorbis format, 44100 Hz. The first track has turned out to be mono, while the second is stereo - could this have any relation?

[flibitijibibo]

If they're both 44.1KHz then yeah, I think it's a channel count mismatch.

[Daaaav]

The music file in question: https://cdn.discordapp.com/attachments/665284975905603584/998285107536343160/vvvvvvmusic.vvv

And my level to test it with: vvvvvvmusic_sped.vvvvvv.zip

[Fussmatte]

OK, I was wrong about stereo/mono, but I was right that they were mismatched. The longer track is 48 kHz. I don't know what I'm thinking, they were mismatched in both ways. The problem persisted after changing the mono track to stereo, though.

I'll test one more time with completely matched specs just to see if it works then.

[Fussmatte]

I've confirmed that after fixing the mismatched sample rates and channels, the audio files work fine in-game.

I guess the question now is whether to fix the audio corruption if they are mismatched, because people might not immediately know if they have incompatible files until their eardrums have been thoroughly ruptured (at least if they're on Linux, evidently). It'd probably be nice to alleviate responsibility for sample rates and stuff from the user, anyway.

[flibitijibibo]

We can either assert or we can pool the voices differently. I think we may have done that recently anyway...? But yeah, stb_vorbis provides this and it can be passed straight to FAudio_CreateSourceVoice.

[Daaaav]

In the latest level contest, a few more audio issues came to light because I was using 2.4 to play the levels. I don't know if both of these are caused by the exact same issue, but even if they're different, it can't hurt to have one issue for all current FAudio issues that all need to be fixed, and all these problems would probably be solved in one go anyway.

• Two of the levels coincidentally are in the situation that they use a sample rate of 48000 for most, but not the first, of their songs. The sample rate of the first song that is played in a level seems to stick for all the next songs that will be played, so if the first played song is 44100, all 48000 songs will play at 0.91875x speed. The songs weren't distorted, and they didn't sound "wrong" to me because I wasn't familiar with them, they were just played in a different key.
• One of the levels has a stereo crumble.wav with a bit depth of 8, when the normal crumble.wav is mono and has a bit depth of 16. It consistently sounds like loud white noise in 2.4, when it's clearly not supposed to. In this case, the sample rate is the one thing that's the same (44100 for both)

Here is a level (somewhat elaborately) demonstrating both these issues: faudio_issues.zip

And also some demo videos (don't forget to unmute them).

The seconds of blackness in the middle of this video is just me restarting VVVVVV, but exiting to the levels menu also works to reinitialize the audio system:

https://user-images.githubusercontent.com/44736680/200099018-7244d6e8-c2f9-46d8-925a-e28cda773cde.mp4

I have to stress, make sure your volume is not too loud for the next video. It's short and not unexpected, but still:

https://user-images.githubusercontent.com/44736680/200099062-9c96fc44-db5e-4818-be9f-1b08bd82a1c9.mp4

[AllyTally]

I'd like to mention that even an exported file straight from FL Studio seems to trigger this bug, where the sound is played as very loud noise instead.

[InfoTeddy]

Good news: I have discovered a workaround to the music bug instead of actually fixing it. Simply call MusicTrack::Halt() at the top of MusicTrack::Play(). Good idea or no?