Quoting: slaapliedje

Quoting: GuestIt's weird seeing so many think this is a good pattern and praising MS for being gamer friendly lately. Does no one else see these grabs as a great lock-in? Give it a little time, buy another beloved studio or three, then start the MS store exclusivity. With no other possibility from any of those shell publishers anymore, it will be a forced success - what Epic tried but with the capital to pull it off. And then, it could even be a simple swap to UWP and game over WINE/Proton.

Seriously.

Within recent years; inXile, Obsidian, Bethesda. Now Activision/Blizzard.

Still laughing that so many journalists are rounding off to 70 Billion... ignoring the 1.3 Billion dollar difference between 70 and 68.7...

https://www.youtube.com/watch?v=tbVb63qPDQ8 [External Link]

Well they are not wrong. That it happens to be 68.7bn is just a side effect of Microsoft having to buy ActivisionBlizzard of the stock market, had they dealt with a single owner then it would have been 70bn and people like nice round numbers.

View this comment - View article - View full comments

Quoting: Guest

Quoting: LordDaveTheKind

Quoting: GuestDon't forget Nintendo off that list

I recall there are a few constraints on acquiring a Japanese company. Am I wrong?

No idea, but it looks like everyone missed this [External Link]point.

A lot can happen in 21 years though.

Quoting: BielFPsThe only factor that I can think it could prevent this acquisition would be Tecent.

Depends on what kind of Money MS would throw at then, I think the right amount would make Tencent sell, isn't that their entire business with Epic, to draw up the worth of it to sell it all for a huge profit? Or do we see Tencent as a long time owner?

View this comment - View article - View full comments

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 :smile: - that's the beauty of FOSS, we can set our systems as we need them. :grin:

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 [External Link] 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 :huh:

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 :tongue:) 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?! :cry:

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 [External Link] 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/ [External Link]

Pluton 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 :huh: are not those for Linux yet or what :dizzy:

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