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

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

 




W dniu 20.02.2021 o 16:31, Chris Brannon via orca-list pisze:
> Michał Zegan <webczat_200@xxxxxxxxxxxxxx> writes:
> 
>> 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?
> 
> In 21 years of Linux experience, I have used nohup about 5 times, all of
> them as a method of last resort.  When services are not managed by an
> init system of some kind, they aren't guaranteed to be reliable and
> always ready to use.
note that, in context of an X session, a session manager was actually
managing background processes on ix.
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.
> 
> As for going against the grain of Unix, consider one of my machines that
> is mostly used headless but which does have console access.  It has some
> speakers hooked up to it, and I typically log in to it over ssh and play
> audio to the room.  I don't want my audio stream dying just because I
> decided to close my ssh session.  A Unix system should well be able to
> do things on my behalf without me being logged in.
This is exactly the use case for system instance of sound server. And As
I have said, pipewire supports that ... almost, and is definitely going
to add a system service file officially.
What I meant is mostly systems where you use both console and gui in
parallel, not headless. and not console-only.
> 
>> 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...
> 
> I do that.  I've been known to run browsers in virtual machines for
> security and privacy.  X is network transparent; it can be tunneled over
> ssh too.  Pulseaudio is network transparent.  Speech Dispatcher is
> network transparent, though I'd suggest that most of the time the best
> approach is to forward its Unix-domain socket over an ssh connection
> (yeah you can do that).
I mostly meant us doing things like rdp, because I am pretty sure
wayland/pipewire are pretty friendly to such solutions, and in that case
we need to be nice to pipewire. I believe when it does not try to take
over sound devices it would likely even work, but I am not sure.
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 am thinking about how to have a second computer without having a
second computer, like using a possibly non rooted android phone to
access a remote machine I lost sound on, or machine over some uart. But
that is besides the topic.
> 
>> 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.
> 
> Do they really need audio access?  If not, then leave them out of the
> appropriate groups.  On my system those would be pulse-access and
> audio.  If they do need audio and they're doinking with it, then map a
> custom key to reset the audio config and unmute the audio.  This is
> Linux, the world is your oyster.
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.
I would definitely be able to, but I noticed I become more and more lazy
in that regard, and it's still true that you need to reset audio
configuration. If you have two users including you who need audio but
they have different settings, imagine apps playing on different cards,
you just break each other's settings instead of each maintaining them,
so the solution is not ideal. And the fact the case when this is
important may be rare... as soon as you hit that case it becomes your
problem, so better for it not to even appear in the first place. Why
can't we work towards something more ideal that also works for these
cases, if that's even doable at all? I think it may be. If it's not,
system wide sound system is acceptable... probably.
I want something that may require changes to pipewire but doesn't
require, or requires minimal, changes to everything else like
screenreader software.
> 
>> 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?
> 
> See above; pulseaudio and Speech Dispatcher are both
> network-transparent.  All of the thin clients I've encountered lacked
> audio hardware, but there's no reason they couldn't have it nowadays.
> Especially if they support USB.
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. I even believe that
way may be cheaper.
And yes, I am not trying to say it's something everyone would do, but
the same would be true for thin clients.
> 
>> Especially on wayland world. Yes I know wayland has
>> accessibility problems at the moment.
> 
> There is waypipe for network transparency.  If wayland becomes widely
> adopted, this kind of thing is going to be made to work, because there
> are a lot of us out there that make use of network transparency.
Hey, how isn't wayland widely adopted? As in I thought each distro
defaults to wayland maybe except ubuntu but not sure, and the only thing
I could say is that it isn't widely adopted by *us*. I may have outdated
info, however.
> 
> -- 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@xxxxxxxxxxxxxxxxx
> _______________________________________________
> orca-list mailing list
> orca-list@xxxxxxxxx
> https://mail.gnome.org/mailman/listinfo/orca-list
> Orca wiki: https://wiki.gnome.org/Projects/Orca
> Orca documentation: https://help.gnome.org/users/orca/stable/
> GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
> 

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Linux for the Blind]     [Fedora Discussioin]     [Linux Kernel]     [Yosemite News]     [Big List of Linux Books]

  Powered by Linux