Re: [orca-list] Solving screenreader sound problems in presence of sound servers once and for all



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]