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

[Chris Brannon <chris the-brannons com>]

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.

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.

> 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.

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.

> 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.

-- Chris

-- 
Chris Brannon
Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/).
Personal website: (https://the-brannons.com/)
Chat: IRC: teiresias on freenode, XMPP: chris chat number89 net