Windows crashes on certain audio formats

Question

Windows crashes on certain audio formats

barbeque-squared opened this issue 9 months ago · comments

This is from the top of my head, but there is definitely a difference in how Windows vs Linux handles files they cannot play. I suspect it has to do with Windows using BASS whereas Linux uses FFmpeg.

Linux behaviour:
If Linux encounters an audio file it cannot play (this is usually something that is 24-bit), it:

does not play preview audio
if you try to sing the song, it just ends immediately

Windows behaviour:
If Windows encounters an audio file it cannot play, it immediately crashes to the desktop. If you have preview audio on, just pressing right, right, right, right in the song collection and it will crash the instant the song gets selected.
I've seen Windows crash on at least:

24-bit
some (not all?) flacs (maybe s16 vs s16le or something?)
opus

I see two possible solutions:

delete BASS decoder entirely, isn't it shipped with FFmpeg for the videos anyway?
make BASS do the FFmpeg behaviour instead of crashing

Option 1 has my preference because it both gives better behaviour as well as supports more formats, but if that's hard to implement option 2 is also still an improvement over just completely killing the application.

s09bQ5 · Answer 1 · Thu Oct 05 2023 00:14:18 GMT+0800 (China Standard Time)

Linux has problems with 24-bit files? Should be easy to fix that.

I never understood why BASS is used on Windows. Was this done to avoid patent issues?

Markus Böhning · Answer 2 · Thu Oct 05 2023 00:41:43 GMT+0800 (China Standard Time)

I don’t know the details about why BASS was/is used on Windows, maybe @basisbit or @brunzel know more? It probably makes a lot of sense to get rid of BASS and harmonize the usage of FFMPEG on all three platforms IMHO.

Stefan · Answer 3 · Mon Oct 09 2023 01:39:28 GMT+0800 (China Standard Time)

Bass was used for the Windows release because all the other options didn't work back at the time when mp3 was still patented and SDL library had no audio input/output device support itself.

Stefan · Answer 4 · Mon Oct 09 2023 01:40:46 GMT+0800 (China Standard Time)

I absolutely favor using ffmpeg for everything that it supports, but I assume that for audio input and output you'll still need bass for Windows, until someone implements the audio input/output support which current version of SDL bring along afaik.

s09bQ5 · Answer 5 · Mon Oct 09 2023 02:52:26 GMT+0800 (China Standard Time)

I absolutely favor using ffmpeg for everything that it supports, but I assume that for audio input and output you'll still need bass for Windows, until someone implements the audio input/output support which current version of SDL bring along afaik.

What is wrong with the current implementation in UAudioInput_SDL.pas and UAudioPlayback_SDL.pas? And why did you rule out our PortAudio code?

Stefan · Answer 6 · Mon Oct 09 2023 05:05:38 GMT+0800 (China Standard Time)

PortAudio on Windows is a UX nightmare and reliability nightmare. It shows the same input devices multiple times through the different available Windows APIs and doesn't filter for the API with the lowest latency. It would need quite a couple of hours of extra development time to make the portaudio variant properly usable under windows.

s09bQ5 · Answer 7 · Mon Oct 09 2023 05:29:27 GMT+0800 (China Standard Time)

SDL doesn't care about the latency when selecting the backend. On Windows it tries WASAPI, DirectSound, and WinMM in that order and uses the first one that works. It will not use more than one backend at the same time. According to this WASAPI is the lowest level API of those three.

Stefan · Answer 8 · Mon Oct 09 2023 05:50:50 GMT+0800 (China Standard Time)

On Windows it tries WASAPI, DirectSound, and WinMM in that order and uses the first one that works.

@s09bQ5 Does SDL do this for each input & output device? That would be perfect

s09bQ5 · Answer 9 · Mon Oct 09 2023 05:59:43 GMT+0800 (China Standard Time)

Once SDL manages to sucessfully initialize an audio backend, it will only list and use devices of that backend.

Stefan · Answer 10 · Mon Oct 09 2023 06:12:10 GMT+0800 (China Standard Time)

😩😩😩
meh, then it is probably not a good option to switch to that. I have already seen a few setups where some mics were only available over WASAPI, and some others only through WinMM/MME.
Guess it is time to open an issue in the SDL issue tracker...

barbeque-squared · Answer 11 · Mon Nov 13 2023 22:14:59 GMT+0800 (China Standard Time)

okay, none of this makes any sense.
Locally I use MSYS, the pipeline uses the dpr thing.

I've added some logging to know for sure which audio output is being used.

Both my local builds as well as the CI use Bass for audio output, do mp3 decoding with Bass, and decode other formats with FFMpeg. This works absolutely fine if I use my local build, but it crashes with the CI build.
At a glance, the only differences I can see are in the .exe size -- my local build is under 3MB, the CI one is over 8MB.

I did mess around a bit with my local build with the switches.inc but the furthest I got with that was that it just wasn't playing the song -- the game didn't crash, which is basically the Linux behaviour. Clearly the CI build is doing something different but I don't know what.

Probably relevant output below:

Local build:

fpc -Si -Sg- -Sc- -v0Binwe -Xs- -O2 -k"-z noexecstack" -k" -L/mingw64/lib" -Fi../src/lib/JEDI-SDL/SDL/Pas -Fu. -FU../build/fpc-i386-win32 -o../game/ultrastardx.exe ultrastardx.dpr
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling ultrastardx.dpr

CI:

Info: (lazarus) Executable="c:\newpascal\fpc\bin\i386-win32\fpc.exe"
Info: (lazarus) Param[0]="-B"
Info: (lazarus) Param[1]="-Pi386"
Info: (lazarus) Param[2]="-MObjFPC"
Info: (lazarus) Param[3]="-Si"
Info: (lazarus) Param[4]="-CX"
Info: (lazarus) Param[5]="-Ciro"
Info: (lazarus) Param[6]="-O2"
Info: (lazarus) Param[7]="-gs"
Info: (lazarus) Param[8]="-gl"
Info: (lazarus) Param[9]="-XX"
Info: (lazarus) Param[10]="-vewibq"
Info: (lazarus) Param[11]="-vn-h-"
Info: (lazarus) Param[12]="-FuC:\projects\usdx\src\base"
Info: (lazarus) Param[13]="-FuC:\projects\usdx\src\lua"
Info: (lazarus) Param[14]="-FuC:\projects\usdx\src\media"
Info: (lazarus) Param[15]="-FuC:\projects\usdx\src\menu"
Info: (lazarus) Param[16]="-FuC:\projects\usdx\src\screens"
Info: (lazarus) Param[17]="-FuC:\projects\usdx\src\lib\dglOpenGL"
Info: (lazarus) Param[18]="-FuC:\projects\usdx\src\lib\SDL2"
Info: (lazarus) Param[19]="-FuC:\projects\usdx\src\lib\portaudio"
Info: (lazarus) Param[20]="-FuC:\projects\usdx\src\lib\ffmpeg-3.1"
Info: (lazarus) Param[21]="-FuC:\projects\usdx\src\lib\SQLite"
Info: (lazarus) Param[22]="-FuC:\projects\usdx\src\lib\other"
Info: (lazarus) Param[23]="-FuC:\projects\usdx\src\lib\openCV"
Info: (lazarus) Param[24]="-FuC:\projects\usdx\src\webSDK"
Info: (lazarus) Param[25]="-FuC:\projects\usdx\src\webSDK\encrypt"
Info: (lazarus) Param[26]="-Fuc:\newpascal\lazarus\components\lazutils"
Info: (lazarus) Param[27]="-FuC:\projects\usdx\src\lib\freetype"
Info: (lazarus) Param[28]="-FuC:\projects\usdx\src\lib\bass"
Info: (lazarus) Param[29]="-FuC:\projects\usdx\src\lib\Lua"
Info: (lazarus) Param[30]="-FuC:\projects\usdx\src\screens\controllers"
Info: (lazarus) Param[31]="-FuC:\projects\usdx\src\screens\views"
Info: (lazarus) Param[32]="-FuC:\projects\usdx\src\lib\midi"
Info: (lazarus) Param[33]="-Fuc:\newpascal\lazarus\components\lazutils\lib\i386-win32"
Info: (lazarus) Param[34]="-Fuc:\newpascal\lazarus\packager\units\i386-win32"
Info: (lazarus) Param[35]="-FuC:\projects\usdx\src\"
Info: (lazarus) Param[36]="-FUC:\projects\usdx\build\fpc-i386-win32\"
Info: (lazarus) Param[37]="-FEC:\projects\usdx\game\"
Info: (lazarus) Param[38]="ultrastardx.dpr"
Free Pascal Compiler version 3.1.1 [2017/03/01] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
(1002) Target OS: Win32 for i386
(3104) Compiling ultrastardx.dpr

s09bQ5 · Answer 12 · Mon Nov 13 2023 22:48:57 GMT+0800 (China Standard Time)

The CI uses a much older Free Pascal version and it has debugging symbols, range checks and integer overflow checks enabled.

There were stack alignment issues on Linux with old Free Pascal versions that affected SSE code in FFMpeg, but Windows never guaranteed 16 byte stack alignment with 32 bit code.

No window with a stack trace when it crashes?
Can you run the executable in a debugger?
Put the .debug files from the game folder next to the DLLs to allow addresses to be resolved.

Does the v2023.5.0 CI build crash on these songs?
Does it crash if you also pass -Ciro to fpc?
Does it crash if you downgrade fpc to 3.1.1?

barbeque-squared · Answer 13 · Mon Nov 27 2023 23:44:22 GMT+0800 (China Standard Time)

(sorry, this took a while to get around to)
@s09bQ5

No window with a stack trace when it crashes?

the error was taken with the CI version. The last line in Error.log at the time of crashing is this one:

INFO:   Using decoder FFmpeg_Decoder for "C:\Users\bbq\Desktop\usdxportable\UltraStar.Deluxe_v2023dev_portable\songs\Wolfcora Zebry - B??se Stuten\Du bist ein Wunder (Karaoke Version) [f3rfSkBCTT8].opus" [TAudioPlaybackBase.OpenDecodeStream]

Audio file in question is the .opus stream from youtube f3rfSkBCTT8 (but I'm pretty sure any opus will trigger this)

Does the v2023.5.0 CI build crash on these songs?

Does it crash if you also pass -Ciro to fpc?

I added -Ciro -gl to the PFLAGS_BASE_DEFAULT line in src/Makefile.in:

the -gl was to get the debug symbols to do anything. If I remove -Ciro again it plays the file just fine

Does it crash if you downgrade fpc to 3.1.1?

I cannot easily test this but considering the above findings I don't think this is related to the fpc version.

s09bQ5 · Answer 14 · Sun Dec 03 2023 08:22:45 GMT+0800 (China Standard Time)

Line 1388 in UAudioDecoder_FFmpeg.pas is

BufferPtr := @Buffer[BufferPos];

Buffer is a pointer to a TByteArray and TByteArray is defined as array of 32768 bytes. The disassembly shows that fpc_rangeerror is called in this line when BufferPos is larger than 32767 and that there is no other error checking in this line. Lines 1334, 1357, and 1365 make sure that BufferPos is positive and smaller than BufferSize. So I assume that BASS sometimes passes a buffer that is larger than 32768 bytes. Can you verify that this is the case?

barbeque-squared · Answer 15 · Sun Dec 03 2023 18:26:41 GMT+0800 (China Standard Time)

tldr; yes it looks like BASS can pass buffers > 32768 bytes.

For this specific opus file, both with and without -Ciro the ReadData function gets called (the first time) with a BufferSize = 38400.

When it crashes (with -Ciro) at line 1338 BufferPos=33312. This is the 10th time it calls that line.

If I remove -Ciro it also gets called with BufferPos=33312, and even one more iteration with BufferPos=37152. After that the entire function gets called again (BufferSize=28800) and in further calls the BufferSize eventually fluctuates between 19000 and 19400.

I did some extra investigation and the code also works with -Cio aka it is indeed the -Cr option that 'causes' it (more like why is the buffer so big to begin with, but I wouldn't know where to start).

s09bQ5 · Answer 16 · Sun Dec 03 2023 21:17:57 GMT+0800 (China Standard Time)

Of course it works if we tell the compiler to stop checking.
But the proper fix would be to change PByteArray to PByte - everywhere there might be a buffer larger than 32768 bytes.

What is the benefit of PByteArray over PByte anyway when Free Pascal allows the array operator to be used on pointers like in C?

barbeque-squared · Answer 17 · Mon Dec 04 2023 23:07:55 GMT+0800 (China Standard Time)

I think you're right about the PByte here. I did some searching in the repo and apparently this isn't the first time this has come up; there have been discussions/commits about this in December 2016 and January 2017 which I've listed in chronological order here:
#187
6cac983
#211
#217

I don't know if it was changed before this, but using PByte seems reasonable.

barbeque-squared · Answer 18 · Thu Dec 21 2023 00:09:08 GMT+0800 (China Standard Time)

I think I have it fixed, PR incoming.
Funny detail: one of my other test files has always worked fine but the initial buffer size is 35280. This is actually also larger than PByteArray, but the error has never gone off. I'm assuming this is because BufferPos itself is never too big for the -Cr to cause it to fail -- even if it's then totally happy to read bytes it's not supposed to.

The file in question is flac, I also heard from others that some opus file do actually work. Yeah I'd rather we support all of them.