[-] Ullebe1@lemmy.ml 6 points 9 months ago

I mean most things are implemented as plugins, so you can just disable the ones with features you consider bloat.

[-] Ullebe1@lemmy.ml 6 points 10 months ago

That seems like a shortcoming in those tools, that I'd expect them to fix as Flatpaks are pretty commonplace.

[-] Ullebe1@lemmy.ml 3 points 1 year ago

Please elaborate.

[-] Ullebe1@lemmy.ml 2 points 1 year ago

It uses FCM for the notifications.

[-] Ullebe1@lemmy.ml 4 points 1 year ago

Do you have a source for the claim that collecting userdata is ultimately what funds Matrix?

[-] Ullebe1@lemmy.ml 3 points 1 year ago

Does this support DRM protected streams, for example with Widevine? Whether one likes DRM or not, it is clear that support for it is a hard requirement for any streaming apps to support this.

[-] Ullebe1@lemmy.ml 4 points 1 year ago

Won't most of those pieces of software work on xwayland?

[-] Ullebe1@lemmy.ml 6 points 1 year ago

I guess that depends on which power your agenda aligns with. That power is generally a safe choice, compared to services from a power where your agenda is orthogonal.

[-] Ullebe1@lemmy.ml 1 points 1 year ago

I live in a time where I don't need to edit config files by hand to allow using multiple applications with the same audio output, since I use a sound server. If you're willing to do it by hand, then by all means continue. Though it does seem that ALSA has had support for automatically setting up dmix since 2005, after PulseAudio was released.

I also don't know if resampling and the like is automatically handled when using dmix, but perhaps you can tell me that, since it sounds like you have experience with it?

Reading the fucking manual suggests that [..]

How about we keep a good fucking tone. Yes, that's great. However my experience is that programs all want to set those properties without a way to disable it, so in practice it doesn't really matter.

Yeah, as you mention hardware mixing used to be an option, but AFAIK hardware generally hasn't supported that for a long time.

Another reason to use Pipewire is to enable sandboxed access to multimedia devices, for use with things like Flatpak or Snap.

[-] Ullebe1@lemmy.ml 4 points 1 year ago* (last edited 1 year ago)

For the multiplexing, as I mentioned.

A V4L2 camera can only be opened by a single application at a time, but if that application is Pipewire, then Pipewire can allow multiple applications to make use of it simultaneously. Same thing with ALSA, it's the reason sound servers exist at all, though I suspect you're already familiar with that.

I also hear that ALSA has some support for multiple applications per device nowadays, though I understand it is much less pleasant to use than a fully featured sound server.

[-] Ullebe1@lemmy.ml 1 points 1 year ago

Because it is convenient for programs to use Pipewire for screensharing, as those programs can then also use the same Pipewire support for all their audio and webcam needs. Also Pipewire is good at multiplexing the various media streams.

[-] Ullebe1@lemmy.ml 6 points 1 year ago

Because Pipewire only handles and understands media streams, so it can stream the output of a window or the whole desktop, but only because the Wayland compositor has already composed the windows and other data it gets from the application to a visual and hands the final result to Pipewire.

view more: ‹ prev next ›

Ullebe1

joined 2 years ago