Quoting: BlackBloodRum

Quoting: F.UltraDo note that there are plenty of bug reports of VLC stuttering with ALSA as well so there is no guarantee that those specific problems are down to Pulse. Pipewire is better yes, but that does still not mean that it will magically solve problems that wasn't due to Pulse, it's just that the bad state of ALSA (yes ALSA) when Pulse became widespread gave Pulse a bad reputation and now everyone blames every single problem on Pulse which leads to the real source of those issues not being fixed.

One advantage of pipewire as well is that it replaces ALSA/JACK as well - providing an interface that applications can understand while at the same time using a much needed overhaul of the codebase.

Previously with pulse it simply had ALSA/Jack running through it - instead of replacing the interface. This is often what caused the latency in the first place as it added an additional step of using multiple audio systems which got in the way.

Meanwhile with pipewire it simply replaces pulse, alsa and jack all at once with it's own interfaces, while they are still technically alsa and jack they are much more refined (think of it like only getting the bits you need, instead of everything). This is why the latency issues are mostly resolved because you are no longer having to run multiple audio systems to get sound, it's just the one (a system with pipewire properly installed doesn't need to have alsa/jack installed, pipewire handles this directly).

This also makes the codebase far easier to maintain - application has broken sound? Well we've only got to check pipewire's code for the problem, instead of trying to determine if it's in alsa, pulse or jack and then trying to contact those developers etc.

I'm not claiming it will magically solve everything, I'm simply saying it may be worth trying it on pipewire as it may (or may not) fix the issue - as whether you like pulseaudio or not you cannot deny all the issues it caused over the years and pipewire has solved many of them.

Give it a try, you might be surprised at just how well it works. No need to argue over this though, you're welcome to stay with pulseaudio and never install pipewire if you prefer and I will use pipewire as it meets my requirements better than pulse - that's the beauty of FOSS, we can set our systems as we need them.

Well a problem here is that this is only half true, yes Pipe replaces pulse and jack but no it does not change anything in regards to ALSA. Note that the solution in WINE to reduce the stutters is to use PULSE_LATENCY_MSEC=60, the default is 5.5ms so what WINE has to do is to increase the buffer size and hence increase the latency in order to keep up.

Pulse never had "ALSO/Jack running through it", Pulse uses ALSA for the output just like Pipe does, there is zero changes here. The main difference between the two is that Pipe doesn't use the rewind feature in ALSA while Pulse is built around it and rewind is apparently rewind is still semibroken in most ALSA drivers.

So you still have to check both the client, Pipewire and ALSA when problems occur just like you would with Pulse, zero differences in that regard. Pipe just replaces Pulse on a 1:1 regard for 99% of all setups (aka the ones that don't also run jack).

The introduced latency is due to pulse giving clients a buffered interface so that they don't have to worry about realtime scheduling in order to keep up with feeding the audio system data, pipe changes nothing in this regard either.

There is no denying that Pipe is better than Pulse in many regards, but it's not a panacea. The problems with sound dropouts and latency in games lies often elsewhere, switching between Pipe and Pulse will simply stir in the pot of random that will solve it for game X but create new problems with game Y. Or if we are lucky then the WINE driver for Pipe will simply be better written than the driver for Pulse and Pipe will take the credit, such is life sometimes.

View this comment - View article - View full comments

Quoting: BlackBloodRum

Quoting: F.UltraThe sound issues in games are not really due to Pulse but down to WINE (hence why they also had to implement a PIPEWIRE_LATENCY env variable) or rather that it's still not clear exactly how the Windows sound system handles buffers, the wine wiki points to this bug https://bugs.winehq.org/show_bug.cgi?id=39814 as reference as "known bug in wine for sound issues" and reading it gives me the impression that games asks for a specific sized buffer but then tries to overwrite it before its consumed in full so there are bugs (in that they don't follow the written spec for the API) in lots of games that the Windows audio system somehow have workarounds for.

That may be true for wine in some cases. However, you should also note that pulseaudio had stuttering and delay issues even for applications that are not wine (for example, Kodi and VLC). I remember when pulseaudio first replaced alsa - there was problems in just about everything after.

In any case while pulseaudio worked for the most part and did improve in many areas - pipewire is far superior in many aspects.

For example, pulse would often struggle with some bluetooth codecs and may have sound issues with bluetooth, where as pipewire works perfectly with aptX codecs (no tweaking, out the box) and all other BT codecs so now my sennheiser momentum 3s can happily play along using the aptx codec without doing workarounds.

It also solves the jack latency issues and random issues where pulseaudio would get confused with too many sinks and you'd have to kill pulseaudio and restart it to make it work again etc.

In any case, you're better off with pipewire at this point.

I hated PA when it first came out, and I still hold a grudge to it now for all the trouble it caused me over the years

With that said I've experienced issues with pipewire too for example sometimes when playing audio at 96kHz/24bit or above it could "pop" occasionally - but then resume playing normally (no need to reboot it or reset it like pulse ) although that issue seems to have been solved as I haven't noticed it lately.

Long story short, neither system is perfect. But pipewire is better.

Just my 2p

Do note that there are plenty of bug reports of VLC stuttering with ALSA as well so there is no guarantee that those specific problems are down to Pulse. Pipewire is better yes, but that does still not mean that it will magically solve problems that wasn't due to Pulse, it's just that the bad state of ALSA (yes ALSA) when Pulse became widespread gave Pulse a bad reputation and now everyone blames every single problem on Pulse which leads to the real source of those issues not being fixed.

View this comment - View article - View full comments

Quoting: BlackBloodRumOh.. noo!

I always try to avoid buying non-linux games.. but.. but.. but.. but.. it's.. it's.. god of war!

aahh..! I used to love this game on the PS!

What to do?!

PS: Regarding the pulse latency environment variable: Have you tried the game with pipewire? does the issue persist? It might be something pipewire can fix - it solves a ton of other old pulseaudio issues. In my experience - sound stuttering and audio sync issues were almost always something caused by pulseaudio itself.

The sound issues in games are not really due to Pulse but down to WINE (hence why they also had to implement a PIPEWIRE_LATENCY env variable) or rather that it's still not clear exactly how the Windows sound system handles buffers, the wine wiki points to this bug https://bugs.winehq.org/show_bug.cgi?id=39814 as reference as "known bug in wine for sound issues" and reading it gives me the impression that games asks for a specific sized buffer but then tries to overwrite it before its consumed in full so there are bugs (in that they don't follow the written spec for the API) in lots of games that the Windows audio system somehow have workarounds for.

View this comment - View article - View full comments

Quoting: NociferI think it's not so much about copyright infringement as it is about the right to distribute the library on its own

So basically Copyright infringement ;)

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: NezchanScience ghosts!

Science ghosts sciencing chocolate!

Well if we are to use the "ghost speak" used by (the silly) ghost hunters then it would be "ghosts doing ghost science with ghost chocolate".

View this comment - View article - View full comments

Quoting: ShmerlSome messed up details here: https://arstechnica.com/information-technology/2022/01/pluton-microsofts-new-security-chip-will-finally-be-put-to-the-test/

QuotePluton will also be responsible for automatically delivering firmware updates through the Windows Update. By tightly integrating hardware and software, Microsoft expects Pluton to seamlessly install security patches as needed.

Yeah, and how is that supposed to work on Linux?

Honestly I think that Ars got that backwards. The chip does not contain any network capability what so ever from what I can find. Instead it looks like Microsoft is going to use the cryptographic capabilities of the chip to perform the authentication of the Windows Update patches instead of doing them in userspace and they are going to use the "Microsoft Pluton" name for their new NIH fwupd competitor where they will either force or ask nicely all hw manufacturers to send their firmware updates through Microsoft.

Linux is not involved here since no distro that I know of even use TPM for anything like this today. Microsoft can do this since they have made TPM2.0 or Pluton mandatory for Windows 11 so they know that every single hw out there that they run on will have this capability.

edit: The real downside here is that they refuse to jump on the fwupd bandwagon and decided to make their own.

View this comment - View article - View full comments

Quoting: ShmerlHow is that Pluton different from current TPMs? Though I'm suspicious of MS being involved in it.

Basically it's TPM but built into the CPU instead of an external chip. The main rationale is that all attacks today against TPM happens in the interface between the CPU and the TPM so moving it into the CPU removes that potential exploit. It's also designed to be able to be have its firmware updated but at the same time designed so the secrets protected by the chip is not made available to the firmware itself.

So this is basically TPM3.0 but with a new fancy name.

View this comment - View article - View full comments

Quoting: dziadulewiczWhat's with these numerous Windows specificisms are not those for Linux yet or what

Add note about available update (enabled in Windows)

Apply proper theme to Windows version of app

Set theme for Windows

Bump QT version used in Windows Release to 5.15

Since Windows don't have distributions applications needs to provide their own update method and also bundle a specific version of e.g QT. Theming I have no idea about.

View this comment - View article - View full comments

Quoting: pete910

Quoting: F.Ultrapiper/libratbag

If I am to be brutal it's just not up to the task for keyboards, Yes it can do the RGB but very basic, Openrgb is demonstrably better. thing with the g915 after 5 mins or so it reverts back to it's default profile.

Regards the actual Keyboard, piper is just not up to it. At the end of the day piper was/is aimed at mice.

Quoting: F.Ultraedit: Missed that support for G915 was new in this version of OpenRGB so don't know if support is better or worse in OpenRGB vs Piper.

I've ran the git on both for some time.

Just to clarify I AM NOT BASHING piper, It's purely aimed at mice and only recently branched out into keyboards from what I can gather.

Thanks for the info. Who knows, all of a sudden perhaps OpenRGB is also the better choice for mice. As of now the work is way to fragmented over piper, openrgb and the one for razor mice (that also have added support for logitech mice of course...) so we have to see if there is one that becomes the defacto standard or if there simple always will be multiple solutions.

View this comment - View article - View full comments

Quoting: pete910The G915 is very buggy on *nix, Due to the fact Logitech thought it would be a good idea to NOT use the onboard memory by default for the profiles ect. Just a FYI the keyboard itself works fine, its the lighting/profiles thats not.


I did setup a vm to use Ghub, What a peace of crap that is. For some weird reason if you set it to onboard mode it greys out most of the options

May have been spoiled by my roccat gear as that worked flawless due to the roccat-tools ect.

Sorry all , rant over!

Yes GHUB is one large piece of crap. Have you tried piper/libratbag? AFAIK they should have LED support for the G915 (despite the name they handle Keyboards as well).

edit: Missed that support for G915 was new in this version of OpenRGB so don't know if support is better or worse in OpenRGB vs Piper.

View this comment - View article - View full comments