inline W dniu 20.02.2021 o 15:32, Chris Brannon pisze:
Michał Zegan <webczat_200 poczta onet pl> writes:Well, if you have pulseaudio installed and running per user, then I doupt you can get sound working in console without any hacks, definitely not before you log in to text mode. In case of system wide pulseaudio you would be using a deprecated configuration.Pulseaudio in system mode is not deprecated. However it isn't recommended by the pulseaudio devs. I ignore that recommendation. It works well, and it is perfectly performant. You can download my configuration from (https://the-brannons.com/pulse-config.tar.gz). I use that configuration on Void Linux. You may need to tweak it for other distros. You'll also have to enable the pulseaudio service in your init system.
That is going to be true for pipewire except it's likely not going to discourage using system wide, officially. So that would work.
The multiseat / multiuser desktop stuff is for big institutional / corporate users. The vast majority of blind people tend to monopolize a Linux machine so it effectively just has one human user. I'm sure this is true of everyone running Linux et al on a laptop or desktop. All of the logind and swarm of per-user autospawning daemons stuff goes against the grain of Unix, as well as making a system unstable and unpredictable.
This I don't get, at least not fully. What is a problem with spawning per user services without something like starting things with nohup? And I really don't get the part about instability. I would say it works very well in general. As for blind people monopolizing desktop, maybe, but you don't know all use cases we face. Assuming that kind of usage is the only one is a bit short sighted, and although system wide sound server would work, things like me just remoting to my machine and needing a gui are so hard to imagine? It's definitely possible to do it somehow, but I don't know any solution that just works with sound support, at least for now. Maybe one exists... And note multiuser also covers one user at a time, but different than the main user, and I was definitely doing that. Like your pc is temporarily being used by some sighted folks. And they decide to mute the sound. oh yeah, all sound is now muted, not only his, because sound server is running system wide. For some reason they often mute the sound :) Because of per user sound server, in case of gui logins, you can have your own per user sound settings without needing root to tweak stuff. And people are pretty creative at times when it goes to the way they use their things, so don't assume they won't do something just because. If system wide pulseaudio is enough for you, it's nice that it's working, but you cannot say there are no people affected by the fact it's system wide. It's non default configuration, needs to be known and understood by users, so if you could *just* run espeakup without any reconfiguration and have it all just working, wouldn't it be nicer?
The right way to share a Linux machine among multiple physical users is to have dedicated thin clients AKA X terminals that all have their own dedicated I/O hardware.
and what uses the hardware? I mean, don't you need apps at the server side to connect to the sound server on the thin client? How do you config that? Especially on wayland world. Yes I know wayland has accessibility problems at the moment.
espeakup and Speech Dispatcher can share a systemwide pulseaudio just fine, even with Speech Dispatcher running per-user. Speaking of Speech Dispatcher, I will be forking speechd-up soon, because it has been effectively unmaintained for years. Announcement forthcoming.
yeah.
Pipewire has a pulseaudio compatibility mode to ease adoption, so why is it particularly relevant here?
Because it also replaces jack, and the pulseaudio compatibility layer means compatibility with pulseaudio clients, does not mean compatibility with pulseaudio configuration, with pulseaudio modules or things like that.
-- Chris
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature