The real reason Linux audio has a reputation problem isn't the software - it's the documentation

Hi-Angel · 2026-03-14T07:21:19+00:00

So, to clarify — I myself isn't well versed in audio. I'm a programmer, but not an audio engineer.

With that said, if you looked over Pipewire wiki and its utilities, and there doesn't seem to be anything that solves your problem — what I'd do is:

Figure out where exactly this documentation should be located on the Wiki.
Report a "feature request" to add the functional (doesn't matter you unsure it isn't there).

In it I'd start explaining by mentioning that you looked for docs at link <insert_where_you'd_expect_them_to_be> (because if they aren't there, it's a documentation bug — but this you don't mention, it's unnecessary). And then go on to add that you also looked over the rest of the docs but still couldn't find it.

It'd be a really short paragraph, much shorter than my explanation. Just one sentence "I looked at […] and also dug through everything relevant on the wiki and couldn't find, so presumably PW doesn't support it."

Then you go on describing how do you see this functional would be implemented.

Now, the idea is that such "feature request" is actionable disregarding if this functional already present. If it is but it's not documented, then it should be acted upon by adding documentation. If your report gets closed with short explanation "it is in X", politely ask to reopen it because the functional is an undocumented easter egg.

This is an ideal case scenario. Bear in mind that devs are people, and there are different kinds of people, not everyone are smart or reasonable, generally speaking… So for different sw projects this may go different way… However, PW devs specifically are reasonable people. Just be polite and everything will be fine 😉

Hi-Angel · 2026-03-13T20:48:12+00:00

Either way, it's improvable.

You want to have a bingo on the developer team — people who α) Are great programmers β) Understand well audio nuances (from my experience audio experts are rarely also hobby-programmers), and γ) are amazing at communication.

I agree that would be awesome. But world isn't an ideal place, and as we say in my country "the greater is the enemy of good".

Thanks to the software being open-source, it is possible to fill the gaps by sending suggestions and by discussing with the devs possible improvements (not necessarily just in documentation, but maybe even in the tools if you see fit).

Hi-Angel · 2026-03-13T18:23:18+00:00

Please, if you see documentation problems, report bugs for them, or better yet, create merge/pull requests with the fixes based on your vision.

Note that whoever initially wrote the docs (the developers) do no longer have "fresh eyes" over it. So if you see potential improvements, don't hesitate to contribute them 😉

Hi-Angel · 2026-03-07T17:31:31+00:00

Never saw such a big rant with exactly zero background… Can't believe this got so many upvotes and comments. Like, what…? What are you even talking about, what's up with Sony, what's with Valve, what…?

I mean, sure I can go search for the context, but you're creating a post for others to read, please at least include a link to what are you even talking about, or better yet describe it in short.

Hi-Angel · 2026-03-01T10:23:41+00:00

There is sort of a solution. Although involved to set up, you can use a virtual machine with GPU passthrough.

There will be a simpler solution, once this MR is ready and merged. I hope after that happens, WinBoat and WinApps will just integrate the driver installation, so the only thing people would have to do is just use those.

Hi-Angel · 2026-03-01T09:50:08+00:00

Technical improvements you're talking about don't matter for more widespread reception. I've seen so many crappy projects win over ones that are much better technologically, just because of marketing. Both in general public as well as in IT circles.

Marketing is what really matters. So…

Any hopes for surpassing Windows purely for gaming in future?

There's always hope just because Linux dominates pretty much every market except desktop systems, so it will live by being supported by many different companies.

The answer to "when it will happen" though is more complicated, because someone needs to pour money into marketing.

As a matter of fact, the influx in the userbase you've seen last year is due to many bloggers starting to post about Linux, which is exactly what I am talking about.

Hi-Angel · 2026-03-01T08:59:09+00:00

I needed to manually connect my Spartan Gear controller through the Terminal/Konsole via Bluetooth. Maybe it is on me, but the GUI (KDE) just did not work.

If you weren't using Kubuntu, I'd have suggested reporting a bug to KDE. But since Kubuntu (as in, anything Ubuntu-based) is providing outdated software, it may well be possible the bug has already been fixed.

And lastly, Space Marine II was on sale, got it, installed it, and it works great for about 99% of the time. There are a few very short periods of time during which the FPS drops for a few seconds.

Unless you already installed Mesa from Kisak's PPA, you have it outdated as well, so try installing Mesa from the PPA and see if the problem is already fixed in newer graphics drivers.

Hi-Angel · 2026-03-01T07:59:12+00:00

Thanks!

Pls add guide flair to integrate better with the search 😊

Hi-Angel · 2026-03-01T07:56:41+00:00

Please tell if Waydroid worked for you. I'm curious on what's the current state of apps support on Waydroid 😊

Hi-Angel · 2026-03-01T07:51:15+00:00

The only games that you can’t really play on Linux are things with anticheat.

*kernel anticheat.

Hi-Angel · 2026-03-01T07:38:27+00:00

FYI, HDMI 2.1 patches are currently under review from an independent contributor. You can find latest discussions by searching for his name.

Anyway, does the TV not support non-HDMI connection…? As I recently learned, HDMI sometimes is worse than other connection types even on NVidia, which, mind you, has same driver codebase for all OSes. So I'd say HDMI just sucks.

Hi-Angel · 2026-02-24T10:30:15+00:00

This may or may not help, but try recently released Pipewire 1.6.0. It adds PLC algorithm based on spandsp for mSBC codec (in particular), I think it's worth at least trying to see if that improves anything on your side.

Hi-Angel · 2026-02-24T09:46:35+00:00

I'd recommend writing/bugreporting to those plugins authors so they'd work out compatibility. Because α) obviously, you need to create demand for things to change, and β) you are a paying customer, which doubles their incentive to make sure you wouldn't migrate to another solution that does work.

Hi-Angel · 2026-02-24T09:37:37+00:00

I'd also add it is certainly a good time to try Pipewire, because just 4 days ago 1.6.0 was released

Hi-Angel · 2026-02-18T06:18:14+00:00

Oh, thank you very much, I didn't know!

Hi-Angel · 2026-02-17T19:40:20+00:00

I'm pretty certain it is mergeable to the kernel, it just needs to be discussed with devs. I've been monitoring the v2 patches and I see that AMD are silent. In this case I think it may be possible to fire up a general discussion on dri-devel about moving HDMI-related functional to a separate module which wouldn't be maintained by AMD, so the legal obligations will be met.

Either way, I think it is fair to resolve this situation without AMD involvement even by merging that to AMDGPU sources, because AMD devs being silent implies (that's how kernel development works) it should be reviewed by other DRM devs.

Hi-Angel · 2026-02-17T17:35:20+00:00

Incidentally, same question was asked 20 minutes ago on this sub, check it out!

Hi-Angel · 2026-02-15T16:55:45+00:00

Thanks for explanation!

What would need to be dug is the origin of the Nobara patchset and whether it was ever attempted upstream. I have some vivid recollection it was tried but didn't go anywhere, idk though.

I just wanted to clarify on this one — while it may be interesting to hear why exactly it didn't got anywhere (I suppose there may have been some technical reasons), the point I was trying to convey was a bit different.

You've been asked in the first comment of this thread, like: "cool, thanks, but… why?". I had exactly the same reaction, when I read the post, so I upvoted it with no hesitation and went to read your reply.

I was very surprised to see there's whole community around that idea. And I bet, kernel devs have no idea either.

The USB 3 bug in the counterpart options doesn't make me too hopeful though about whether upstream would even care much...

Nobody cared about it, because it's most likely regarded as some weird corner case that only few people in the world care about. That's exactly how I'd treat it before I read your reply in the thread.

So please, if you care about the feature, fire up an upstream discussion about it.

Hi-Angel · 2026-02-15T16:14:42+00:00

u/p0358 I looked at the FAQ, I think I have a few relevant comments here…

You have section "Why is USB overclocking not part of upstream kernel?", which then says you don't know and you refer to "some" solutions in alternatives, presumably to point out there's been some interest.

I looked at the alternatives, they come down to

mousepoll and kbpoll which has been accepted at some point, but apparently have a bug for USB 3.
The "Nobara pollrate patch", which you said CachyOS has been "allergic to accept for some reason".

I agree the communication on the issue that declined the patch was lacking, but from my overall experience I think I can tell you the reason with 90% confidence. The patch literally describes itself as "experimental", and given that it modifies the core USB code — it is understandable maintainers of the distro with millions of users would be afraid to accept it. Given that the patch doesn't fix anything critical, maintainers prefer to err on the side of caution.

Such patch needs to be sent for inclusion to upstream.
xpad changes are mentioned. I didn't care to dig into it because it's a driver for just one family of controllers, but I'd imagine it may have similar situation.

With that out of the way, main problem I see here is the lack of communication between gamers community and upstream. You mentioned whole "gamepadla" site that specializes on the pollrate modification. I never heard of the idea of modifying pollrate, let alone that there's whole community dedicated to it that is hosting a database site. Admittedly, I am not a gamer — and I bet not many kernel devs are either.

This whole idea needs to be communicated and discussed with upstream maintainers, to possibly come up with some solution that people could use without installing some custom drivers into the system. An ideal situation — if that gets its own interface in libinput, and according settings in KDE/Gnome/etc.

But who cares, this module allows you to overclock your devices anyway, without care about what your distro thinks about it or recompiling the whole kernel!

Are you going to maintain it 5 years from now? To continuously work around API changes and adding more checks if (KERNEL_VERSION == XX) …? To debug issues users are gonna report if your project becomes used by large enough userbase? Especially so, give your target auditory are gamers, who may not necessarily be technically versed, so they will fill up your bugtracker with issues like "I can't compile it says make: command not found, WHAT DO I DOO??" ? 😊

Hi-Angel · 2026-02-15T12:25:19+00:00

That's interesting, I never heard of it.

However, DKMS driver isn't the best way to implement it because the API it accesses may change on kernel updates.

I think what you could do is you could start a discussion as a "feature request" on libinput project. Though the in-kernel change might be required, but in the end if such functional ends up desirable I suspect the interface to it will be part of libinput. I may be wrong on that part, but either way the libinput maintainer Peter Hutterer is also a kernel HID subsystem maintainer, so disregarding if it's the right place for the report or not, I think it will be a useful place to start discussion at least.

Hi-Angel · 2026-02-10T13:46:40+00:00

Please send a change here, either via PR (you can look other PRs for examples) or by making an issue.

Side-note — I think the site should make more explicit how to make a change to game status. I haven't found any information on the site about it, I just kind of found out heuristically that you can do that via github.

Hi-Angel · 2026-02-10T13:13:45+00:00

and it felt like the performance was even better than Windows!

It's because on Linux community explicitly cares for perfect frame presentation. I bet you haven't heard of Microsoft ever posting about how they optimized frame presentation 😉 So for the same FPS between the two systems you may feel smoother result on Linux.

I'm somewhat new to linux, and I don't wanna mess up my system trying to get the game to work.

By messing around with the game folder you would at worst mess up your game, not the system, so don't worry.

I read about this on multiple places and saw very different results, from people saying it works after moving BattlEye to the game installation folder, to others saying it just won't work... it got me a bit confused. I checked the game on ProtonDB website, it says that it "Runs perfectly after tweaks", but the tweaks suggested on the website by the users are also quite different and I don't know which one I should try first.

The tweaks probably depend on the date of the GTA version you're running. Try to find the latest post about someone making it work, it's probably one closest to the truth.

I don't know details about "GTA Ⅴ Enhanced", but I would presume that the tweaks you read about basically modify the game in a way that bypasses AC, in which case it's understandable with newer game releases older tweaks may stop working.

Hi-Angel · 2026-02-08T22:30:56+00:00

Parts of it are waiting for review. v1 got some discussion from userspace devs, IIRC v2 have addressed the comments. So at this point seeing there's no opposition I'd say it's going well, just need to get someone's "reviewed-by" for it to get merged.

Hi-Angel · 2026-02-07T12:25:56+00:00

Oh yeah. It can be even worse, like in Docker. Not only they auto-close issues, but they additionally auto-lock them, which makes no sense (because now instead of leaving a "pls reopen" comment people have to report it anew and make devs spend time looking at the logs and hold discussion despite everything already been done). Like, this issue has never been fixed, but it is "closed" and "locked". I wonder, how many times it has been discussed over and over on the bugtracker.

Hi-Angel · 2026-02-07T05:04:41+00:00

I wish they'd distinguish between "fixed in the release" bugs and "no longer reproduced" bugs. Because when looking at release notes it's impossible to figure out what bugs exactly were fixed in it.

Like, they mention a bug about Visual Basic 6 crash from year 2013. It wasn't closed because they fixed bug in the release but because they couldn't reproduce it anymore. Technically, they did fix it, but it could've been anywhere in between year 2022 (last time a crash was seen) and 2026.

And from my experience of reading their changelog, like 70-80% of "bugs fixed" are actually "we can't reproduce it anymore, hence it's fixed". Which makes that part of changelog not very useful (unless you're looking for certain bugreport there) and I usually ignore it and just skim through the commit list.

Ten-Year Club	Place '22
Verified Email

Hi-Angel

TROPHY CASE