It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
rojimboo: I'm not sure I've seen more passive aggressive tech support.
1.You must have not been in too many tech support forums.
2.If you are offended then I apologize. Tho I am too tired with IRL BS to have any patience for people that want support but refuse to answer questions because they think they know better :S
I am trying to remain nice, but whoever wants help needs to understand that cooperation is a 2 side activity, not "I dump my problem and will pick answers based on my convenience".
I mean no harm.
avatar
B1tF1ghter: 1.You must have not been in too many tech support forums.
2.If you are offended then I apologize. Tho I am too tired with IRL BS to have any patience for people that want support but refuse to answer questions because they think they know better :S
I am trying to remain nice, but whoever wants help needs to understand that cooperation is a 2 side activity, not "I dump my problem and will pick answers based on my convenience".
I mean no harm.
No worries, I just thought I would mention it since dtgreene seems to be under 'attack' for asking support in a troubleshooting thread :)

We all have our bad days, and I know you're volunteering help, but if it's too much for you maybe just take a break from it for a while.

Troubleshooting is fun when you get to fix stuff - not so much when there are endless unrelated issues with no solution to be found.
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.)
avatar
dtgreene: 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.
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)

avatar
dtgreene: Also, it helps that JACK has a GUI utility (qjackctl) that allows me to tweak things like the buffer size (which affects latency).
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?

avatar
dtgreene: 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.
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.

avatar
Srtola: Hola, tengo un juego de la compañia Deep silver. ¿como pueod reclamar el deadight?
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).

avatar
dtgreene: 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.)
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)
Post edited March 25, 2021 by B1tF1ghter
avatar
dtgreene: 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.
avatar
B1tF1ghter: 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)
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.


avatar
B1tF1ghter: 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)
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.)
Post edited March 25, 2021 by dtgreene
avatar
B1tF1ghter: 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 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.
avatar
B1tF1ghter: 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)
avatar
dtgreene: 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.
So if I'm getting your config right, ALSA is the default?

avatar
dtgreene: 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.)
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.

avatar
B1tF1ghter: 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?
avatar
dtgreene: I actually *do* have a lot of Linux experience; around a couple decades worth.
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.

avatar
dtgreene: Some questions would take a lot of effort to answer,
Many problems of yours would get fixed faster if you would actually take your time to respond.

avatar
dtgreene: or I have no way of answering them in the first place, hence why I didn't answer every question.
In such case you should say so, and perhaps you would be told how to check something.

avatar
dtgreene: 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.
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.
avatar
dtgreene: Some questions would take a lot of effort to answer,
avatar
B1tF1ghter: Many problems of yours would get fixed faster if you would actually take your time to respond.
Sometimes, getting certain problem fixed faster isn't a priority of mine.

avatar
B1tF1ghter: 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".
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.)
Post edited March 25, 2021 by dtgreene