Just recalled what are the actual problems with system mode pulseaudio and why it's not recommended. I believe pulseaudio uses shared memory to transport data. From what I remember, in system mode it does not use shared memory, just the socket, so just running system wide may, if I understand correctly, affect latency, so depends what you are doing. Pipewire is not going to have this problem. However there we have another problem: if you'd start using flatpak apps, flatpak portal is an user service connected to the user/session bus. So running system wide breaks your ability to use sound through pipewire through flatpak apps, at least in a way it's intended to be used. And these problems are likely things that could affect more users than stuff like per system configuration etc. So I still think someone has to step in a little bit to make both sides happy. W dniu 20.02.2021 o 18:01, Michał Zegan pisze:
W dniu 20.02.2021 o 17:46, Chris Brannon via orca-list pisze:Michał Zegan <webczat_200 poczta onet pl> writes:As for logind and other things, note that pipewire/pulseaudio are now managed by the systemd-user. I mean it works exactly same as the systemd system instance just in user context, and you can make it start on boot, so you get similar reliability as in case of normal system services in a systemd system. Pulseaudio nor pipewire are not started just by the first client that tries to use them, and I even believe the only thing that still does that is speech-dispatcher, unless it changed. Logind causes changes on device acls and mediates access to some other devices, but does not by itself spawn anything, and when it spawns systemd-user it spawns it via systemd, like starts a service, so reliability guarantees of an init system are not broken per my understanding.Well, not everyone uses systemd. And by reliable, I mean always up and ready to do its particular job. Any good init system with service supervision can do that, and systemd is one such init system. Re: logind messing with device ACLs, this is where the always-up reliability gets broken.It doesn't. First it cannot revoke control over these devices if they are already opened, second if you add the thing to audio group it still has access. It's just for managing device ownership for local sessions. It would never affect system services or services having unconditional access to the device, it does not and cannot force-release a device with exception of graphic devices it seems. No one made that impossible.Let me put it a different way. Would a sighted person be happy if their monitor stopped working just because they logged out? I believe not. They expect the same always-up reliability from their screens as I expect from my audio system; it is my primary method of output. Of course that's also a good argument for hardware synths and braille displays, and maybe if Linux audio becomes unreliable, I'll be forced back to a hardware synth out of necessity.I get it, although actually graphic cards are governed by a stronger mechanism that force-switches control between x servers/compositors, so sighted people are more affected than we are, in theory. Although, if I switch user sessions and am sighted, I get my configuration of monitor/etc applied, so ... it's all the same, all the same. X servers are currently also per session, same as wayland compositors. Of course requirements are different, but mechanisms themselves do apply here.As for your suggestions, actually interesting idea it is. The problem happens when the only local computer you have is windows, do you have any way to do it in that case? Or for example some kind of phone.I've never tried. I haven't ran Windows since late 2000 or so. I have no idea about phones, but I could possibly rig something up on Android if I really had to. Before that, though, I think I'd try using something like the Raspberry Pi. I have not tried using it as a GUI thin client yet, though I'm planning on it. For console use it works well as a thin client.Yeah, and here it appears. You need linux to accessibly connect to linux gui. And you are not always in a situation where you have any choices.For instance, right now I'm typing this out on a Pi, in my living room. I run emacs on a shared family server in the back room and forward emacspeak's speech server protocol over a TLS tunnel. So the machine running emacspeak isn't the same one as the machine with the keyboard and audio I/O devices. I could just as easily have my emacs + emacspeak running on some VM in a data center somewhere. Essentially I've got a terminal in my living room.Yes. the thing is how much I or others want to play with it. Like not everyone is sufficiently advanced to do it, and sufficiently motivated.Well there are two conflicting visions of computing here: personal computing and appliance computing. The latter is what's being sold with Windows, Mac OS X et al and by some Linux vendors too. It tries to be one-size-fits-all. The former is a different world. It's the world that gave us Linux to begin with. And usually there's some configuration / customization required, if you expect to get what you want out of it.Well, but it is not either this or that. You should be able to customize things, but necessarily be forced to do it because othervise something doesn't work. Especially if sighted people don't have some problems and we do just because our requirements.Yes, network transparency. However systemd multiseat works by attaching something like a set of devices over usb, like you don't need a full thin client, and you should get everything including audio. I would say it's also a nice way to do it, at least technically.Except that thin clients give you some isolation for free.Everything has pros and cons. I believe for example you get better performance when using usb devices compared to thin clients, especially when it goes to things like sound, as in, if you have to connect over tcp or forwarded unix socket, not sure you can use shared memory. All sound servers like pa/jack probably?/pipewire use shared memory for data transfer, mediated over unix sockets, and I doupt that works over tcp where you cannot even send file descriptors. And not sure what happens if over ssh when you tunnel unix sockets, for example.-- Chris
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature