yes i'm on linux (Debian) and I have purged pulseaudio since it often did not respond. This message happens especially when a large group of spiders is on screen.
Then it seems there're some issues with Alsa mixing or so. Historically ALSA had rather stupid api, where either your sound card got hardware mixer and can play >1 sound at once (but ofc HW only supports limited # of chans) - or no mixing at all. Later ppl got fed up with this and software mixer plugin got added to support SW mixing. Still, it only used on cards where no HW mixer exist.
It's not all the story. Pulseaudio appeared because from app dev point of view alsa api is quite troublesome. Pulseaudio runs on top of alsa, exposing way more sane api to programs - and it can also do resampling, mixing, etc in process. So programs don't have to do hardcore DSP in their code themselves. Either way, due to need to do hardcore DSP processing in app code, plain alsa support in programs and libs could be missing or quite dodgy. I'd say I'll blame ALSA for their weird api and failure to provide sane api to app devs (e.g. saying mixer is "optional" plugin? oh wtf, so everyone still to code their own sound mixing code as fallback path in libs/apps?).
Pulse did that tho - so most apps use it, and/or enjoy far less buggy support. However, pulse inherently does some resamping and mixing to make it up for ALSA api idiocy, it is inherently realtime-critical task. Therefore there're things like rtkit to assign it realtime priority and monitor it. Say Ubuntu setups all this machinery automatically. Debian could be less polished, especially if you go on your own. But if you hate pulse too much, there is "apulse" alsa plugin to pretend you have "pulse audio" when you don't really have one. Haven't tried this one though, so no warranty implied.
TL;DR: seems your sound system bugs app and/or libsdl a bit, not the other way. Guess libsdl2 got more of this stuff sorted out, but still, it's quite uncommon to run apps on just plain alsa. And ofc TMW client have to play >1 sound at once. My guess is that when certain concurrency exceeded your sound system fails to play more sounds, client reports that, what else could it do?
Also if you have whatever sound interruptions, stutter or something... whoever plays games may really want RT_PREEMPT kernels. "Normal" kernels are more suitable for things like SERVERS. I'm not really sure why both Debian and ubuntu install THESE on DESKTOPS by default, maybe to have like 2..5% extra in benchmarks for marketing purposes, etc. However, "server" kernels have considerable task switching latency and it really bad for gaming, sound processing and other "realtime" tasks. So you may want -rt kernels on desktop (linux-image-rt-amd64 package, preferrably recent one from backports, like 5.9).