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@xxxxxxxxxxxxxx> 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
