Update:

I ended up switching to JACK for the sound server, and directing ALSA to point to JACK, and while not perfect, the result is actually better. mplayer fails for whatever reason, but YouTube works well, and the game running under WINE isn't perfect, but the occasional audio glitches are not nearly as bad as the prior situation.

Also, it helps that JACK has a GUI utility (qjackctl) that allows me to tweak things like the buffer size (which affects latency).

JACK was actually already installed, because I was thinking of playing around with programs that require it like supercollider and sonic-pi (and I believe Ardour as well); now that I have actually been able to get it working, I might actually try those programs.

Hola, tengo un juego de la compañia Deep silver. ¿como pueod reclamar el deadight?

Downgraded my kernel from 5.10 (debian bullseye kernel) to 4.19 (debian buster kernel), and it looks like that may have fixed my audio issue.

(This means that there must have been a regression at some point.)

You do know you can have multiple audio backends at once right? (such as pa for normal usage as well as jack2 (btw did you switch to JACK or JACK2?) for proaudio/other software)

Both alsa and pa have utilities for configuration. They usually don't come with GUI per se but I don't see what's the problem. It's not like they do not display visual feedback. It's only a matter of personal bias and unjustified disgust of console based tools at this point.
You will also inevitably have to change some config file by hand at some point, especially in jack.

Also, should you have had chosen answering the questions you would be at the very least directed towards materials that would ensure proper assistance with your pa problem. But instead you refused out of your own... I don't know... ego?
You will inevitably run into issues again sooner or later. After all both jack and jack2 are far more complex than pa.
At that point ask yourself a question once again and at the very least be honest with yourself:
Do you feel confident enough to ask for help of others (based on the fact that you don't possess enough knowledge and experience to fix the problem by yourself) and then refuse to answer your helpers' very valid questions (neccessary for troubleshooting without being physically at your place, and it doesn't matter if you understand the point of asking them for them to still be valid, in fact it's the very fact that people are more experienced than you causing them to ask very specific questions that you may not understand reasoning behind asking for) based on your own personal pretense?

I wish you the best of luck with your problematic endevours.
But I will not waste my own personal time trying to help you if you will keep to pretentiously refuse to answer my valid troubleshooting-related questions.

1.Use english next time. Machine translation isn't exactly of best quality.
2.This thread isn't for these kinds of questions. It's for troubleshooting issues with games played on Linux. NOT with GOG account issues (such as issues with or lack of knowledge how to redeem a key).

I want you to know and understand that what I'm about to say here isn't a personal attack.
I just want to bring you to your senses early on, otherwise either someone else will do that sometime down the line, or you will one day feel the consequences of your mistakes on your own self.

You must seriously not understand how Linux software development works.
According to public info there is 738 days between 4.19.0 and 5.10.0.
I'm assuming you meant LTS (which you failed to speak about).
In case of LTS only security fixes and major bugfixes are backported.
New functionality improvements usually don't find their way into LTS builds. At which point the afformentioned 738 days come into play.
If you fail to understand that this much time is far beyond just regressions, it's literal code rebase then you will run into worse issues other time based on your fundamental lack of understanding of kernel release cycles and what it means to backport stuff, also what LTS is for, and how you can expect software to behave on it.
And no, it most certainly wasn't a regression.
Don't associate problem-on-Linux == regression because things don't work like that by default.
It was 99% certainly a misconfiguration on your end.
Linux isn't Windows.
There is literally the fact that each and every single Linux deployment is it's individual ecosystem where unique issues may arise.
Choosing Linux needs to be done consciously with that in mind.
If you want to use it you must also face the reality - you will not be able to run from problems indefinitely - at some point you will have to spark internal courage to learn to fix them.
It's beyond foolish to jump major kernel versions and expect just minor things to change.
You better buckle up as you are up for the journey of discovering what stopped working and started misbehaving.
Remember. YOU chose this by first asking for help and then refusing to answer debugging questions.
Now you jumped one year of funcionality changes.
At this point helping you becomes a chore and if you keep ignoring people's questions, not just mine but also others', then you will not get anywhere.
Please grow some common sense and be responsible when you ask for help. Troubleshooting and such isn't about someone magically fixing your problems.
You have to cooperate too or you will not get very far.
I hope for your understanding (tho I feel you won't have enough of it for some time).
And have a good day.

edit: fixed broken quotes (rearranged them)

Yes, but I am not that experienced with setting that up.

In any case, JACK (I think it's JACK2, but I'm not sure) is running on the ALSA backend, with ALSA being configured to direct the client programs to JACK via .asoundrc.


I *do* understand how Linux development works.

In any case, the kernels being used are debian's distribution kernels. The 4.19 kernel I'm using is from debian buster; hence, it should keep getting security updates as long as buster is still getting support (and if buster gets LTS, even if only for some packages, the kernel would still continue to get security updates).

I have compiled kernels in the past (including trying out 5.11.8 on my laptop, getting a KVM-enabled kernel for my Raspberry Pi (no longer necessary), and various other versions for virtual machines), so I know how to do that. and am comfortable doing so.

If I felt like it, I could probably try to bisect the issue (using "git bisect"; linux (the kernel) is maintained as a public git repository), and figure out what commit caused the issue, but that would take some time, and for now I don't feel like investing that time.

Also, it is a regression; it works properly in an older kernel version but not a newer one, so by definition, it is a regression. (Don't forget that the kernel has a strict "don't break userspace" policy.)

I actually *do* have a lot of Linux experience; around a couple decades worth.

Some questions would take a lot of effort to answer, or I have no way of answering them in the first place, hence why I didn't answer every question.

Also, I am allowed to decide that I don't need the help badly enough to put forth the answer to every question, and I would prefer if I would not be berated for doing so.

In any case, I've found a solution that works well enough for my purposes.

So if I'm getting your config right, ALSA is the default?

No it's not neccessarily a regression.
I think you misunderstand.
There is just WAY TOO MUCH differences within more than 700 days of code to talk just about a regression.
The code entirely changed in entire AREAS.
A regression can be a thing when you can actually pinpoint difference between a specific piece of code involved.
Of course such long span regressions DO exist. But it's not very usual. And it doesn't have to be the sole reason for something to be broken.
Do you know why it doesn't have to be a regression?
Because if new functionality is introduced within few month window, then code usually changes placement within binaries (rarely it actually causes issues), and config files often change syntax (well frequency depends on a package, but generally it can actually be frequent, in any case 2 YEARS is long enough for a whole plethora of packages to change their config files syntax and deprecate some commands) which in particular DOES cause sh*t to break if proper maintenance is not done.
I don't know how Debian handles changes to config files (I use Arch, which has rather barebones approach, which FOR ME is better since I HATE blackbox designs, and configuring everything from ground up allows me to actually KNOW what's where so then if there is a problem then I don't have to look all other the place because I KNOW what I configured how as opposed to having to look up default values on some "less barebones" distro).
But it could be that some change was not carried over or the file got carried over raw and suddenly old syntax was mixed with new one (upon update) thus causing all sorts of stupid sh*t.
I don't know.
But don't associate "it doesn't work after update" == "It's definitely regression" because it could not work due to other reasons.

That's a totally worthless statement.
I was specificly referring to heavily narrowed down area you are having issues with. If you cannot fix it yourself it usually means you don't know enough. And there's nothing wrong with that.
I don't care to know "everything". I have my areas of expertise and don't pretend to be "know it all".
What I'm saying is you shouldn't be pretentious when someone more experienced in the area tries to help you.

Many problems of yours would get fixed faster if you would actually take your time to respond.

In such case you should say so, and perhaps you would be told how to check something.

I would prefer if people would not leave their "closed on their end" tickets open indefinitely, making people working on them bother themselves with it longer than neccessary.
If you are content with your situation on an issue and no longer need support then say so IMMEDIATELLY instead of going all "I think I'm done, but I'm going to casually confuse this guy trying to help me by answering some of his questions while TOTALLY IGNORING others and all that while I no longer need help".

dtgreene, B1tF1ghter, if you plan to keep going on for a while, maybe it would be best to open a dedicated thread?
This thread is usually the go-to place for quick troubleshooting, but for the last days it has been flooded by your back and forth, scaring away anyone that could have asked for help on their own issues.

Sometimes, getting certain problem fixed faster isn't a priority of mine.

Consider that I no longer need support on the issues I've posted up to this point.

(This doesnt' apply to any issues I post later, of course.)

I have spent hours trying to get my starwars republic commando to launch and it just wont, I already tried making it compatible with windows XP pack 3, nothing works.

Did anyone try running Beyond A Steel Sky (latest version)? I get some massive memory leak in the intro and it just crashes all the time becasue of OOM.

Do you mean native or through wine?

PCGW has no info on memory leaks for this game (but PCGW isn't always 100% complete).
I have no clue what could cause mem leaks in this particular game so I'm afraid I can't help you with this side of the coin.

However you may want to try to RAM limit the game process itself for the sake of reducing general system OOM (to avoid system crash/lock).
You may want to play around with various RAM usage limiting software.
Or try running it in a container (like firejail or apparmor).
Upon brief checkup I found these:
https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-single-linux-process
https://stackoverflow.com/questions/26860822/how-limit-memory-usage-for-a-single-linux-process-and-not-kill-the-process
https://askubuntu.com/questions/510913/how-to-set-a-memory-limit-for-a-specific-process
and generally consensus is that using custom cgroups and assigning PIDs to them is a good way to go, tho you cannot use cgroups on just about any distro (some don't support it ootb).

Just for debugging sake:
how much RAM do you have?
Do you have SWAP? (how much, what swappiness)

What distro btw?

Native. It's clearly a bug because the game eats all RAM (I have 32 GB which is more than enough) and OOM monitor kills the process. Debian testing, kernel 5.12.8, tried with different versions of Mesa, including Mesa master. GPU - AMD RX 5700 XT.

Did you update the BIOS for this? These cards had some problems... Not knowledgable enough to tell whether those problems could really affect system RAM.

It's Sapphire Pulse. I don't think there is any update for what comes with it.