Solving screenreader sound problems in presence of sound servers once and for all

Solving screenreader sound problems in presence of sound servers once and for all

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 2785 bytes --]

Hi,
Sending that mail to orca and speakup lists, because I am asking for
ideas from the blind community especially console screenreader developers.
There is now a new sound server called pipewire that seems to merge good
sides of both pulseaudio and jack, I am just testing it and working with
it daily, and except some sound stuttering and other bugs it's really
usable and stable. It is currently in active development, but ready for
wider testing.
I think this is a good opportunity to fix, or take part in fixing, our
problem: how to get sound in console, including pre login and post
login, without having to either uninstall any and all sound systems and
lose their capabilities, or hack around/work around the issue?
I think we have to step in at least when it comes to ideas, because I
don't think they know how to do it properly, and honestly, me neither.
Pipewire will support, and I think already does support, running as a
system wide process, and that would technically solve the problem,
except it has it's drawbacks. Note pipewire, like pa and jack, is
normally running as an user service, and I think for good reasons, at
least in case of graphical sessions.
It would be definitely visible to those using user accounts because
users won't have their own sound settings etc. Possibly other use cases
may also not be possible or become hacky, like multiseat or remote
desktop with sound. There are also security related drawbacks to system
wide pipewire, and some of us may care, like one user being able to
influence other user's sound.
Does anyone have any ideas about how the problem could be solved without
sacrificing things like pipewire's low latency goals? I do have some but
not sure how well would they work, like some way to handover devices
between system wide and user wide instances, and either a way to switch
between pipewires on the fly from a system service like espeakup/fenrir,
or in case of things like fenrir, being able to run multiple instances
of fenrir and being able to handover when switching sessions/vt's.
Or some way to still use system wide server in case of console sessions,
but not sure how that would be implemented considering how device
handover normally works.
Note pipewire is now started by systemd user, so it's not per session,
it's per user. So you cannot just not start it on console login because
you may be using both a gui and a console, for example. and possibly
three ssh sessions, this probably starts pipewire too even though ssh
sessions are non local and would not cause sound device handover themselves.

Waiting for some insight on that. We may contact developers on gitlab or
irc, but today is saturday and the main pw dev is unavailable.
Best regards,
Michał Zegan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Didier Spaier]

Hi Michał

I don't understand the issue stated in the quoted part of your message 
below:

Le 20/02/2021 à 13:38, Michał Zegan a écrit :
> I think this is a good opportunity to fix, or take part in fixing, our
> problem: how to get sound in console, including pre login and post
> login, without having to either uninstall any and all sound systems and
> lose their capabilities, or hack around/work around the issue?
Which sound system(s) do you currently have to uninstall to get sound in
console? I ask because here I have Alsa and PulseAudio installed and 
still get
sound on console (and also in Mate at the same time).

Could you please elaborate?

Best regards,
Didier

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]

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. It's still not an ideal solution to the problem, like
stated above.

W dniu 20.02.2021 o 14:03, Didier Spaier pisze:
> Hi Michał
> 
> I don't understand the issue stated in the quoted part of your message
> below:
> 
> Le 20/02/2021 à 13:38, Michał Zegan a écrit :
>> I think this is a good opportunity to fix, or take part in fixing, our
>> problem: how to get sound in console, including pre login and post
>> login, without having to either uninstall any and all sound systems and
>> lose their capabilities, or hack around/work around the issue?
> Which sound system(s) do you currently have to uninstall to get sound in
> console? I ask because here I have Alsa and PulseAudio installed and
> still get
> sound on console (and also in Mate at the same time).
> 
> Could you please elaborate?
> 
> Best regards,
> Didier
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Chris Brannon]

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.

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.

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.

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.

Pipewire has a pulseaudio compatibility mode to ease adoption, so why
is it particularly relevant here?

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

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 4191 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Chris Brannon]

Michał Zegan <webczat_200@poczta.onet.pl> 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.

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.

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

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

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

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

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

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

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 7177 bytes --]



W dniu 20.02.2021 o 16:31, Chris Brannon via orca-list pisze:
> Michał Zegan <webczat_200@poczta.onet.pl> 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@chat.number89.net
> _______________________________________________
> orca-list mailing list
> orca-list@gnome.org
> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Chris Brannon]

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

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

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 5697 bytes --]



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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 6757 bytes --]

Just recalled what are the actual problems with system mode pulseaudio
and why it's not recommended.
I believe pulseaudio uses shared memory to transport data. From what I
remember, in system mode it does not use shared memory, just the socket,
so just running system wide may, if I understand correctly, affect
latency, so depends what you are doing.
Pipewire is not going to have this problem. However there we have
another problem: if you'd start using flatpak apps, flatpak portal is an
user service connected to the user/session bus. So running system wide
breaks your ability to use sound through pipewire through flatpak apps,
at least in a way it's intended to be used.
And these problems are likely things that could affect more users than
stuff like per system configuration etc.
So I still think someone has to step in a little bit to make both sides
happy.

W dniu 20.02.2021 o 18:01, Michał Zegan pisze:
> 
> 
> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Didier Spaier]

Hi Chris,
as soon as done I'll be more than happy to ask users to try it in Slint, 
which
currently includes speechd-up 0.5 alongside espeakup and fenrir.

So yes, please let us know. Will you set up a public Git repo?

Best regards,
Didier


Le 20/02/2021 à 15:32, Chris Brannon a écrit :
> Speaking of Speech
> Dispatcher, I will be forking speechd-up soon, because it has been
> effectively unmaintained for years.  Announcement forthcoming.

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Mike Ray]

In:

https://github.com/cromarty/ttsprojects/

I have a hacked version of speechd-up to which I have added absent
volume controls.

I have tested it some, but probably needs more.

I have no qualms about running pulse in system-wide mode either.

Mike




On 20/02/2021 16:14, Didier Spaier wrote:
> Hi Chris,
> as soon as done I'll be more than happy to ask users to try it in Slint,
> which
> currently includes speechd-up 0.5 alongside espeakup and fenrir.
> 
> So yes, please let us know. Will you set up a public Git repo?
> 
> Best regards,
> Didier
> 
> 
> Le 20/02/2021 à 15:32, Chris Brannon a écrit :
>> Speaking of Speech
>> Dispatcher, I will be forking speechd-up soon, because it has been
>> effectively unmaintained for years.  Announcement forthcoming.
> 
> 


-- 
Michael A. Ray
Analyst/Programmer
Witley, Surrey, South-east UK

"Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away." -- A. de Saint-Exupery


https://cromarty.github.io/
http://eyesfreelinux.ninja/
http://www.raspberryvi.org/

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Chris Brannon]

Didier Spaier <didier@slint.fr> writes:

> So yes, please let us know. Will you set up a public Git repo?

(this is Re: the digression about speechd-up).

Hi Didier,
I certainly will.  It'll be posted on the BLVUUG forge, whenever that's
up and running.  I need to get cracking on that.

I'm going to change the name to speechd-up-ng because I'm making some
changes to it that make it not quite a drop-in replacement for
speechd-up.  E.G., I've removed the dependency on dotconf (never was a
huge fan of that) and instead of autotools, I have a tiny, readable, and
capable makefile.  I've also cut out code to do double forking and
manage pid files etc.

This last is probably of some concern to you, because I suspect slint
probably doesn't have a supervisor that manages foreground services.
You could, for instance, run it under the daemonize utility, which
handles double-forking and pid file management.

-- Chris

Git hosting (was Re: Solving screenreader sound problems ...)

[Jookia]

On Sat, Feb 20, 2021 at 09:44:39AM -0800, Chris Brannon wrote:
> ...
> 
> I certainly will.  It'll be posted on the BLVUUG forge, whenever that's
> up and running.  I need to get cracking on that.
> 
> ...
> 
> -- Chris

Do you have any idea on accessible Git hosting software for this?

Jookia.

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[chris]

Jookia <contact@jookia.org> writes:

> Do you have any idea on accessible Git hosting software for this?

Yes.  I'm probably going with sourcehut, self-hosted.

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

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Jookia]

sourcehut is accessible now? Last I checked it lacks things like skip
links and titles for icons :\

On Wed, Feb 24, 2021 at 09:53:37AM -0800, chris@the-brannons.com wrote:
> Jookia <contact@jookia.org> writes:
> 
> > Do you have any idea on accessible Git hosting software for this?
> 
> Yes.  I'm probably going with sourcehut, self-hosted.

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Chris Brannon]

Jookia <contact@jookia.org> writes:

> sourcehut is accessible now? Last I checked it lacks things like skip
> links and titles for icons :\

Neither are a prerequisite or a blocker for a thing being accessible,
not by a longshot.  Sourcehut has headings, which work just as well
(better?)  than skip links.  And we (me and another blind friend) don't
find the lack of icon titles to be a problem in practice for sourcehut,
either.

It may not meet technical definitions of accessibility, but I'd argue
that it's more usable for us than the competition.

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

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Karen Lewellen]

Chris,
Who exactly is us?
I hope you realize how many millions of blind and vi individuals there are 
in the  world, all of whom use technology differently and have their  own 
preferences?
Speaking personally, it is profoundly frustrating, and counter productive 
when the word accessible gets used  as if it means interchangeable.
After all, there are unfortunately rather a few who believe Linux users do 
not deserve access based on your generalized concept of us.

Just thoughts,
Kare



On Wed, 24 Feb 2021, Chris Brannon wrote:

> Jookia <contact@jookia.org> writes:
>
>> sourcehut is accessible now? Last I checked it lacks things like skip
>> links and titles for icons :\
>
> Neither are a prerequisite or a blocker for a thing being accessible,
> not by a longshot.  Sourcehut has headings, which work just as well
> (better?)  than skip links.  And we (me and another blind friend) don't
> find the lack of icon titles to be a problem in practice for sourcehut,
> either.
>
> It may not meet technical definitions of accessibility, but I'd argue
> that it's more usable for us than the competition.
>
> -- 
> 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
>
>

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[chris]

Karen Lewellen <klewellen@shellworld.net> writes:

> Chris,
> Who exactly is us?
> I hope you realize how many millions of blind and vi individuals there
> are in the  world, all of whom use technology differently and have
> their  own preferences?

Indeed, but at some point you have to have a least common denominator
for accessibility.  For me, that least common denominator would be
"usable from lynx".  That's a very very low bar, and it covers just
about all of us.

The fact is, fewer and fewer things on the web are willing to meet that
least common denominator.  As a user, I've pretty much given up on the
text mode browser, even though I'll keep using them everywhere I can,
till the day I die.  As a service provider, I'm committed to only
hosting services that are usable from a terminal.

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

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Jookia]

I generally go by WCAG 2.1 guidelines at the moment for a definition of
'accessibility'.

Currently the only provider I see that almost fits this bill is GitHub.

On Wed, Feb 24, 2021 at 01:39:33PM -0800, chris@the-brannons.com wrote:
> Indeed, but at some point you have to have a least common denominator
> for accessibility.  For me, that least common denominator would be
> "usable from lynx".  That's a very very low bar, and it covers just
> about all of us.
> 
> The fact is, fewer and fewer things on the web are willing to meet that
> least common denominator.  As a user, I've pretty much given up on the
> text mode browser, even though I'll keep using them everywhere I can,
> till the day I die.  As a service provider, I'm committed to only
> hosting services that are usable from a terminal.
> 
> -- 
> 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
> 

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Chris Brannon]

Jookia <contact@jookia.org> writes:

> I generally go by WCAG 2.1 guidelines at the moment for a definition of
> 'accessibility'.
>
> Currently the only provider I see that almost fits this bill is GitHub.

Github is ok.  But sourcehut is far more usable due to a strong
emphasis on "no bullshit".  You won't find this in guidelines or in
technical definitions.

Do you actually test with screenreaders?  How about Orca?  Do you have
access to a Raspberry Pi 4?  An x86 machine would work, but I think a
Raspberry Pi 4 with Orca is a nice environment for testing.  If you
don't have an installation with Orca easy to hand, but you do have a Pi
4, I can send you an image you could test with.

Assuming you've got Orca running, you should try using the following two
sites in Firefox.  I picked a couple repos at random, for a compare-and-contrast.

https://github.com/curl/curl
https://sr.ht/~vpzom/lotide/

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

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Jookia]

On Wed, Feb 24, 2021 at 11:00:24PM -0800, Chris Brannon wrote:
> Github is ok.  But sourcehut is far more usable due to a strong
> emphasis on "no bullshit".  You won't find this in guidelines or in
> technical definitions.

What is 'no bullshit'? Is it accessibility features that you don't need?

> Do you actually test with screenreaders?  How about Orca?  Do you have
> access to a Raspberry Pi 4?  An x86 machine would work, but I think a
> Raspberry Pi 4 with Orca is a nice environment for testing.  If you
> don't have an installation with Orca easy to hand, but you do have a Pi
> 4, I can send you an image you could test with.

Yes I test with screen readers, but accessibility covers more than just
screen readers. You mentioned earlier that sourcehut has headings that
supposedly work better than skip links- if you're using a screen reader.
If you can see but just can't use a mouse or have some button-based
input then you're kind of screwed here.

> Assuming you've got Orca running, you should try using the following two
> sites in Firefox.  I picked a couple repos at random, for a compare-and-contrast.
> 
> https://github.com/curl/curl
> https://sr.ht/~vpzom/lotide/

GitHub gives me a skip link, then lets me see all the different parts of
the project I can view (issues, releases, etc). The source code view
shows me the directory tree, which commits modified what, how long ago
that was. Things are folded in to dropdown boxes and have icons that
explain things.

Sourcehut is confusing to me even with sight. I go to your link, then I
click 'tickets' and now I can't go to the sources or mailing list.
Tickets has a long table that doesn't tell you what the columns even
are, with a number at the end that I assume is to do with comments or
something. It looks like in order to contribute you have to use mailing
lists and patches which isn't very friendly.
The mailing list tracker has unlabeled numbers that aren't even visually
described. They just show as an arrow and a person for me.
Going to sources shows me a bunch of different repos and clicking those
don't show me how to get back to the larger project. The source doesn't
tell me which commits last modified a file.

Overall I find Sourcehut very hard to navigate and build a mental model
of where things are, and it requires adding an email client to my
workflow instead of just using git and a web browser.

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Chris Brannon]

Jookia <contact@jookia.org> writes:

> What is 'no bullshit'? Is it accessibility features that you don't need?

Javascript that lags my Pi 4 to unusability?  I have an old Acer netbook
that I use while traveling sometimes.  I wouldn't dare try running
firefox on that anymore.  I've had privileged people tell me to get a
newer / faster / more powerful computer.

> Yes I test with screen readers, but accessibility covers more than just
> screen readers.
> You mentioned earlier that sourcehut has headings that
> supposedly work better than skip links- if you're using a screen reader.
> If you can see but just can't use a mouse or have some button-based
> input then you're kind of screwed here.

Ok.  I have no vision.  Not light perception.  Squat.  And I never
have.  That's my frame of reference, my bias.

So sourcehut doesn't have skip links?  Unlike Github, it is free
software.  Has someone tried sending patches?  Were they rejected?  If
they were, then that's a problem.  I'd fork it myself and accept those
patches.

You know, you just gave me an excellent notion.  I've been
told that gitea is hostile to adding accessibility features.  It
supports the kind of pull request workflow popularized by github, and
it's free software.
Now I'm tempted to fork it and solicit accessibility patches.

We have different frames of reference.  You seem like someone I can
work with.  Interested in collaborating on a gitea fork?

> GitHub gives me a skip link, then lets me see all the different parts of
> the project I can view (issues, releases, etc). The source code view
> shows me the directory tree, which commits modified what, how long ago
> that was.

And I find the whole thing confusing and verbose.  It works, but it
isn't pleasant.  Fortunately they have an API and there are command line tools.

> Things are folded in to dropdown boxes and have icons that
> explain things.

If you are a power user, having things explained to you all the time
is just a distraction.  Investing time to learn pays off mightily.
Speech and braille are inherently low-bandwidth channels.  I suspect
screen magnification is somewhat low bandwidth too, just not as strongly.

> Sourcehut is confusing to me even with sight. I go to your link, then I
> click 'tickets' and now I can't go to the sources or mailing list.

Use the back button?  A lot of web applications break the back button,
but on both github and sourcehut it is usable.

> It looks like in order to contribute you have to use mailing
> lists and patches which isn't very friendly.

If you're using git, you're already using a notoriously user-hostile VCS
anyway.  It is widely adopted because Linux uses it and because of
Github.  Is having to use email to submit patches really that much more
of a burden?  I've taught people to get up and running with
git send-email in a matter of minutes.  Patches and email have been around
for decades; they'll be around long after Github is gone, and they work
even in the most constrained of environments.

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

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Jookia]

On Thu, Feb 25, 2021 at 12:44:35AM -0800, Chris Brannon wrote:
> Javascript that lags my Pi 4 to unusability?  I have an old Acer netbook
> that I use while traveling sometimes.  I wouldn't dare try running
> firefox on that anymore.  I've had privileged people tell me to get a
> newer / faster / more powerful computer.

So support for lightweight computers, got it. I'm running on something
with less power than a Raspberry Pi 4 so I get it, I really do.

> Ok.  I have no vision.  Not light perception.  Squat.  And I never
> have.  That's my frame of reference, my bias.

Ok.

> So sourcehut doesn't have skip links?  Unlike Github, it is free
> software.  Has someone tried sending patches?  Were they rejected?  If
> they were, then that's a problem.  I'd fork it myself and accept those
> patches.

Do it then. I've spoken with the author of sourcehut and they don't seem
to really understand accessibility, and sourcehut's actual website and
workflow confuses me too much to actually open an issue.

> You know, you just gave me an excellent notion.  I've been
> told that gitea is hostile to adding accessibility features.  It
> supports the kind of pull request workflow popularized by github, and
> it's free software.
> Now I'm tempted to fork it and solicit accessibility patches.
> 
> We have different frames of reference.  You seem like someone I can
> work with.  Interested in collaborating on a gitea fork?

I'm the only person to my knowlede that has ever implemented
accessibility improvements for Gitea and done an overview of the code.
Gitea isn't hostile to accessibility features, but the codebase is
written in such a way that making the UI elements screen readable would
require a rewrite.
Nobody's stepping up to that task so Gitea accessibility is just a pipe
dream at the moment.

> And I find the whole thing confusing and verbose.  It works, but it
> isn't pleasant.  Fortunately they have an API and there are command line tools.

Does sourcehut have command line tools?

> If you are a power user, having things explained to you all the time
> is just a distraction.  Investing time to learn pays off mightily.
> Speech and braille are inherently low-bandwidth channels.  I suspect
> screen magnification is somewhat low bandwidth too, just not as strongly.

Ok. Do you only care about power users?

> Use the back button?  A lot of web applications break the back button,
> but on both github and sourcehut it is usable.

If someone links me to some patch or some issue, there's no way to go to
the code or other parts of the project. This is a huge navigation issue.

> If you're using git, you're already using a notoriously user-hostile VCS
> anyway.  It is widely adopted because Linux uses it and because of
> Github.  Is having to use email to submit patches really that much more
> of a burden?  I've taught people to get up and running with
> git send-email in a matter of minutes.  Patches and email have been around
> for decades; they'll be around long after Github is gone, and they work
> even in the most constrained of environments.

Yes, it's that much more of a burden. I've tried it with multiple
projects that I've contributed to and found that mail-based workflows
are a lot harder to deal with. Having stuff scattered everywhere instead
of a single page or set of pages is a nightmare for me.

I'm not trying to waste your time by bringing up nitpicks with easy
answers, I'm voicing legitimate accessibility issues that you should be
aware about if you're going to choose to use sourcehut. You will be
excluding a set of users like me from contributing.

Jookia.

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Chris Brannon]

Jookia <contact@jookia.org> writes:

> I'm the only person to my knowlede that has ever implemented
> accessibility improvements for Gitea and done an overview of the code.
> Gitea isn't hostile to accessibility features, but the codebase is
> written in such a way that making the UI elements screen readable would
> require a rewrite.
> Nobody's stepping up to that task so Gitea accessibility is just a pipe
> dream at the moment.

At the moment, ok.  So what my former boss would have called "a simple
matter of effort"?  I probably don't have the web chops for that kind of
a rewrite but I think it is worth my time investigating.

> Does sourcehut have command line tools?

It has an API.  They could be written.  Realize sourcehut has only been
around a couple of years.  But I know blind people who are actively
using it right now and it works well for them in *any browser*.

>> If you are a power user, having things explained to you all the time
>> is just a distraction.  Investing time to learn pays off mightily.
>> Speech and braille are inherently low-bandwidth channels.  I suspect
>> screen magnification is somewhat low bandwidth too, just not as strongly.
>
> Ok. Do you only care about power users?

In some very real sense, yes.  If you don't care about power users first
and foremost, you end up with a bunch of helpless perpetual newbies
using an appliance rather than a tool.  When it breaks or fails to meet
their needs, they have nothing to fall back on but their learned helplessness.

Again, I'll point an accusing finger at git.  It's pretty terrible from
a usability perspective, with its abstractions leaking all over its user
interface and user documentation.  This is the philosophy of only caring
about power users taken to an extreme.

> If someone links me to some patch or some issue, there's no way to go to
> the code or other parts of the project. This is a huge navigation issue.

Legit.

> Yes, it's that much more of a burden. I've tried it with multiple
> projects that I've contributed to and found that mail-based workflows
> are a lot harder to deal with. Having stuff scattered everywhere instead
> of a single page or set of pages is a nightmare for me.

That's fair.

> I'm not trying to waste your time by bringing up nitpicks with easy
> answers, I'm voicing legitimate accessibility issues that you should be
> aware about if you're going to choose to use sourcehut. You will be
> excluding a set of users like me from contributing.

Well, I've scratched it off of my list of things to consider using.  I'm
a Socialist; I really do want to give everyone a pony.

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

Re: Git hosting (was Re: Solving screenreader sound problems ...)

[Janina Sajka]

Yeah, I've seen that "no bs" label on Gandi for years. I have no idea
what it means. To me it's marketing hype that's supposed to make you
comfortable because it's so common person, and not stuffed shirt. But,
that doesn't define accessibility in any way shape or form.

At W3C we use github and I'm perfectly fine with it. I prefer the cli
where the git and hub commands meet almost all my needs.

hth

Janina

Chris Brannon writes:
> Jookia <contact@jookia.org> writes:
> 
> > I generally go by WCAG 2.1 guidelines at the moment for a definition of
> > 'accessibility'.
> >
> > Currently the only provider I see that almost fits this bill is GitHub.
> 
> Github is ok.  But sourcehut is far more usable due to a strong
> emphasis on "no bullshit".  You won't find this in guidelines or in
> technical definitions.
> 
> Do you actually test with screenreaders?  How about Orca?  Do you have
> access to a Raspberry Pi 4?  An x86 machine would work, but I think a
> Raspberry Pi 4 with Orca is a nice environment for testing.  If you
> don't have an installation with Orca easy to hand, but you do have a Pi
> 4, I can send you an image you could test with.
> 
> Assuming you've got Orca running, you should try using the following two
> sites in Firefox.  I picked a couple repos at random, for a compare-and-contrast.
> 
> https://github.com/curl/curl
> https://sr.ht/~vpzom/lotide/
> 
> -- 
> 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

-- 

Janina Sajka
https://linkedin.com/in/jsajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Jookia]

For the past year or so a friend and I have had PulseAudio and espeakup
working together fine on Linux. All you have to do is get Pulse to let
go of control of the sound card when you switch TTYs, or something like
that. It's a combination of udev rule and systemd user service.
With some more tricks you can even get it to speak the bootup sequence
and some logout stuff.

On Sat, Feb 20, 2021 at 01:38:21PM +0100, Michał Zegan wrote:
> Hi,
> Sending that mail to orca and speakup lists, because I am asking for
> ideas from the blind community especially console screenreader developers.
> There is now a new sound server called pipewire that seems to merge good
> sides of both pulseaudio and jack, I am just testing it and working with
> it daily, and except some sound stuttering and other bugs it's really
> usable and stable. It is currently in active development, but ready for
> wider testing.
> I think this is a good opportunity to fix, or take part in fixing, our
> problem: how to get sound in console, including pre login and post
> login, without having to either uninstall any and all sound systems and
> lose their capabilities, or hack around/work around the issue?
> I think we have to step in at least when it comes to ideas, because I
> don't think they know how to do it properly, and honestly, me neither.
> Pipewire will support, and I think already does support, running as a
> system wide process, and that would technically solve the problem,
> except it has it's drawbacks. Note pipewire, like pa and jack, is
> normally running as an user service, and I think for good reasons, at
> least in case of graphical sessions.
> It would be definitely visible to those using user accounts because
> users won't have their own sound settings etc. Possibly other use cases
> may also not be possible or become hacky, like multiseat or remote
> desktop with sound. There are also security related drawbacks to system
> wide pipewire, and some of us may care, like one user being able to
> influence other user's sound.
> Does anyone have any ideas about how the problem could be solved without
> sacrificing things like pipewire's low latency goals? I do have some but
> not sure how well would they work, like some way to handover devices
> between system wide and user wide instances, and either a way to switch
> between pipewires on the fly from a system service like espeakup/fenrir,
> or in case of things like fenrir, being able to run multiple instances
> of fenrir and being able to handover when switching sessions/vt's.
> Or some way to still use system wide server in case of console sessions,
> but not sure how that would be implemented considering how device
> handover normally works.
> Note pipewire is now started by systemd user, so it's not per session,
> it's per user. So you cannot just not start it on console login because
> you may be using both a gui and a console, for example. and possibly
> three ssh sessions, this probably starts pipewire too even though ssh
> sessions are non local and would not cause sound device handover themselves.
> 
> Waiting for some insight on that. We may contact developers on gitlab or
> irc, but today is saturday and the main pw dev is unavailable.
> Best regards,
> Michał Zegan
> 

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 3765 bytes --]

This is the thing, you need hacks to work around stuff, and then you get
drawbacks.
For example does your setup allow me to play sound on gui and hear it on
console when I log in to the same user, or, play sound on console when
screenreader is speaking?
Like the last one is likely possible if espeakup uses dmix.

W dniu 20.02.2021 o 14:08, Jookia pisze:
> For the past year or so a friend and I have had PulseAudio and espeakup
> working together fine on Linux. All you have to do is get Pulse to let
> go of control of the sound card when you switch TTYs, or something like
> that. It's a combination of udev rule and systemd user service.
> With some more tricks you can even get it to speak the bootup sequence
> and some logout stuff.
> 
> On Sat, Feb 20, 2021 at 01:38:21PM +0100, Michał Zegan wrote:
>> Hi,
>> Sending that mail to orca and speakup lists, because I am asking for
>> ideas from the blind community especially console screenreader developers.
>> There is now a new sound server called pipewire that seems to merge good
>> sides of both pulseaudio and jack, I am just testing it and working with
>> it daily, and except some sound stuttering and other bugs it's really
>> usable and stable. It is currently in active development, but ready for
>> wider testing.
>> I think this is a good opportunity to fix, or take part in fixing, our
>> problem: how to get sound in console, including pre login and post
>> login, without having to either uninstall any and all sound systems and
>> lose their capabilities, or hack around/work around the issue?
>> I think we have to step in at least when it comes to ideas, because I
>> don't think they know how to do it properly, and honestly, me neither.
>> Pipewire will support, and I think already does support, running as a
>> system wide process, and that would technically solve the problem,
>> except it has it's drawbacks. Note pipewire, like pa and jack, is
>> normally running as an user service, and I think for good reasons, at
>> least in case of graphical sessions.
>> It would be definitely visible to those using user accounts because
>> users won't have their own sound settings etc. Possibly other use cases
>> may also not be possible or become hacky, like multiseat or remote
>> desktop with sound. There are also security related drawbacks to system
>> wide pipewire, and some of us may care, like one user being able to
>> influence other user's sound.
>> Does anyone have any ideas about how the problem could be solved without
>> sacrificing things like pipewire's low latency goals? I do have some but
>> not sure how well would they work, like some way to handover devices
>> between system wide and user wide instances, and either a way to switch
>> between pipewires on the fly from a system service like espeakup/fenrir,
>> or in case of things like fenrir, being able to run multiple instances
>> of fenrir and being able to handover when switching sessions/vt's.
>> Or some way to still use system wide server in case of console sessions,
>> but not sure how that would be implemented considering how device
>> handover normally works.
>> Note pipewire is now started by systemd user, so it's not per session,
>> it's per user. So you cannot just not start it on console login because
>> you may be using both a gui and a console, for example. and possibly
>> three ssh sessions, this probably starts pipewire too even though ssh
>> sessions are non local and would not cause sound device handover themselves.
>>
>> Waiting for some insight on that. We may contact developers on gitlab or
>> irc, but today is saturday and the main pw dev is unavailable.
>> Best regards,
>> Michał Zegan
>>
> 
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Jookia]

On Sat, Feb 20, 2021 at 02:12:54PM +0100, Michał Zegan wrote:
> This is the thing, you need hacks to work around stuff, and then you get
> drawbacks.
> For example does your setup allow me to play sound on gui and hear it on
> console when I log in to the same user, or, play sound on console when
> screenreader is speaking?
> Like the last one is likely possible if espeakup uses dmix.

Yes to both.

Re: Solving screenreader sound problems in presence of sound servers once and for all

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 1000 bytes --]

How does it work then, if pulseaudio releases device, and some gui
program plays something, it plays on pulseaudio, so you shouldn't be
hearing it on console because pa just released the device.
Also in any case it's still the thing. Things like that should work out
of the box and shouldn't require workarounds. So if there is a proper
way to fix it that would make it hassle free it should be considered to
be pushed upstream, if it cannot be pushed upstream, then the issues
that prevent it should be mitigated.


W dniu 20.02.2021 o 14:18, Jookia pisze:
> On Sat, Feb 20, 2021 at 02:12:54PM +0100, Michał Zegan wrote:
>> This is the thing, you need hacks to work around stuff, and then you get
>> drawbacks.
>> For example does your setup allow me to play sound on gui and hear it on
>> console when I log in to the same user, or, play sound on console when
>> screenreader is speaking?
>> Like the last one is likely possible if espeakup uses dmix.
> 
> Yes to both.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Didier Spaier]

I suggest that you bring this issue to a support channel for your 
distribution
as this works out of the box in others.

There is nothing to be pushed upstream (to ALSA or PulseAudio developers) as
this depends on the configuration provided by the distribution in use or
customized by the user.

Didier

Le 20/02/2021 à 14:23, Michał Zegan via orca-list a écrit :
> How does it work then, if pulseaudio releases device, and some gui
> program plays something, it plays on pulseaudio, so you shouldn't be
> hearing it on console because pa just released the device.
> Also in any case it's still the thing. Things like that should work out
> of the box and shouldn't require workarounds. So if there is a proper
> way to fix it that would make it hassle free it should be considered to
> be pushed upstream, if it cannot be pushed upstream, then the issues
> that prevent it should be mitigated.
> 
> 
> W dniu 20.02.2021 o 14:18, Jookia pisze:
>> On Sat, Feb 20, 2021 at 02:12:54PM +0100, Michał Zegan wrote:
>>> This is the thing, you need hacks to work around stuff, and then you get
>>> drawbacks.
>>> For example does your setup allow me to play sound on gui and hear it on
>>> console when I log in to the same user, or, play sound on console when
>>> screenreader is speaking?
>>> Like the last one is likely possible if espeakup uses dmix.
>>
>> Yes to both.
>>
> 
> 
> _______________________________________________
> orca-list mailing list
> orca-list@gnome.org
> 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
> 

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

[Michał Zegan]

[-- Attachment #1.1: Type: text/plain, Size: 2697 bytes --]

Well,
It is interesting. I haven't tried for some time, however for me, on any
distro I ever touched, per user pulseaudio + things like espeakup never
just worked.
And if they did, it would mean I don't understand something about linux
sound architecture, as all my knowledge suggests it shouldn't work
without, at least, running pulseaudio as a system service or somehow
taking it out of the way at right moments.

W dniu 20.02.2021 o 15:16, Didier Spaier via orca-list pisze:
> I suggest that you bring this issue to a support channel for your
> distribution
> as this works out of the box in others.
> 
> There is nothing to be pushed upstream (to ALSA or PulseAudio
> developers) as
> this depends on the configuration provided by the distribution in use or
> customized by the user.
> 
> Didier
> 
> Le 20/02/2021 à 14:23, Michał Zegan via orca-list a écrit :
>> How does it work then, if pulseaudio releases device, and some gui
>> program plays something, it plays on pulseaudio, so you shouldn't be
>> hearing it on console because pa just released the device.
>> Also in any case it's still the thing. Things like that should work out
>> of the box and shouldn't require workarounds. So if there is a proper
>> way to fix it that would make it hassle free it should be considered to
>> be pushed upstream, if it cannot be pushed upstream, then the issues
>> that prevent it should be mitigated.
>>
>>
>> W dniu 20.02.2021 o 14:18, Jookia pisze:
>>> On Sat, Feb 20, 2021 at 02:12:54PM +0100, Michał Zegan wrote:
>>>> This is the thing, you need hacks to work around stuff, and then you
>>>> get
>>>> drawbacks.
>>>> For example does your setup allow me to play sound on gui and hear
>>>> it on
>>>> console when I log in to the same user, or, play sound on console when
>>>> screenreader is speaking?
>>>> Like the last one is likely possible if espeakup uses dmix.
>>>
>>> Yes to both.
>>>
>>
>>
>> _______________________________________________
>> orca-list mailing list
>> orca-list@gnome.org
>> 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
>>
> _______________________________________________
> orca-list mailing list
> orca-list@gnome.org
> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Didier Spaier]

Hi Matthew,

That was my assumption. In Slint it works out of the box, so it would 
certainly
be possible in Debian if only someone could convince the maintainers of ALSA
and PulseAudio for Debian to use dmix as mixer for PA by default and not
redirect the streams coming from PA to ALSA. But hey, I have written 
that years
ago and am not in concern, sorry for beating this dead horse again.

Le 20/02/2021 à 17:48, ilovecountrymusic483@gmail.com a écrit :
> Didider,
> 
> What I think he is referring to is being able to use orca and speakup at the same time.  Ie using orca with a gui system such as gnome or mate and get speech ina concile with speak-up or fenner.  At the moment, you have to do some editing of some configuration files inorder to get both working orca and speech working together.  At least in Debian, this works in other distros like arch this is not so easy.  HTH.
> 
> Matthew
> 
> 
> 
> -----Original Message-----
> From: orca-list <orca-list-bounces@gnome.org> On Behalf Of Didier Spaier via orca-list
> Sent: Saturday, February 20, 2021 9:17 AM
> To: orca-list@gnome.org; Speakup is a screen review system for Linux. <speakup@linux-speakup.org>
> Subject: Re: [orca-list] Solving screenreader sound problems in presence of sound servers once and for all
> 
> I suggest that you bring this issue to a support channel for your
> distribution
> as this works out of the box in others.
> 
> There is nothing to be pushed upstream (to ALSA or PulseAudio developers) as
> this depends on the configuration provided by the distribution in use or
> customized by the user.
> 
> Didier
> 
> Le 20/02/2021 à 14:23, Michał Zegan via orca-list a écrit :
>> How does it work then, if pulseaudio releases device, and some gui
>> program plays something, it plays on pulseaudio, so you shouldn't be
>> hearing it on console because pa just released the device.
>> Also in any case it's still the thing. Things like that should work out
>> of the box and shouldn't require workarounds. So if there is a proper
>> way to fix it that would make it hassle free it should be considered to
>> be pushed upstream, if it cannot be pushed upstream, then the issues
>> that prevent it should be mitigated.
>>
>>
>> W dniu 20.02.2021 o 14:18, Jookia pisze:
>>> On Sat, Feb 20, 2021 at 02:12:54PM +0100, Michał Zegan wrote:
>>>> This is the thing, you need hacks to work around stuff, and then you get
>>>> drawbacks.
>>>> For example does your setup allow me to play sound on gui and hear it on
>>>> console when I log in to the same user, or, play sound on console when
>>>> screenreader is speaking?
>>>> Like the last one is likely possible if espeakup uses dmix.
>>>
>>> Yes to both.
>>>
>>
>>
>> _______________________________________________
>> orca-list mailing list
>> orca-list@gnome.org
>> 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
>>
> _______________________________________________
> orca-list mailing list
> orca-list@gnome.org
> 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
>