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





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



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