Re: loss of speech in speakup when switching between console and gui

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: loss of speech in speakup when switching between console and gui

Didier Spaier
Hello,

On 06/11/2018 14:52, [hidden email] wrote:
>> I'll let you know how that goes on Slint.
> I know about users who run it on windows, BSD and MacOSX ;) so i assume it runs on Slint too.

It does, I hear a sound when it starts and:

didier[~]$ ps -ef|grep fenrir
didier    2810  2796  1 19:49 pts/0    00:00:00 fenrir
didier    2811  2810  0 19:49 pts/0    00:00:00 /usr/bin/python3 /usr/bin/fenrir
didier    2813  2810  0 19:49 pts/0    00:00:00 /usr/bin/python3 /usr/bin/fenrir
didier    2818  2810  0 19:49 pts/0    00:00:00 /usr/bin/python3 /usr/bin/fenrir
didier    2822  2810  0 19:49 pts/0    00:00:00 /usr/bin/python3 /usr/bin/fenrir
didier    2833  2796  0 19:50 pts/0    00:00:00 grep fenrir
didier[~]

However I don't know how to make it read anything and the keyboard commands don't work
although i have installed these deps:

python-evdev-1.0.0
pyudev-0.21.0
dbus-python3

>> I don't think that can fully replace speakup though ;)
> oh, i would be interested in why? Thats exact the kind of feedback i m looking for :).
> There are already a lot of fenrir only users out there :). but mostly on Arch based systems. so at least for them it seems to be able ;).
> let me know what you think or what is missing. code is nothing fixed or hammered in stone ;) .

Fenrir is mutually exclusive of speakup on the console and orca in graphical mode, which both work well enough.

I'd need to know what benefit could bring to Slint users using fenrir instead before investing more time testing it.

> something off topic,
> i see in slint you ship KDE plasma. i want to give some attention here on our progress to make it accessible. you and maybe others here might be interested in.

Well we still ship KDE4 for now, so that'd be after the release of Slackware 15, maybe mid-2015, if it ships plasma 5.

Thanks for your effort anyway

If you want to further discuss fenrir or Slint I suggest that we do that elsewhere not to spam this list.

Best regards,

Didier

0xD50202EF60C03EEA.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: loss of speech in speakup when switching between console and gui

Didier Spaier
On 06/11/2018 20:04, Didier Spaier wrote:
> Well we still ship KDE4 for now, so that'd be after the release of Slackware 15, maybe mid-2015, if it ships plasma 5.

Please read mid-2019, and that's just an uninformed forecast.

0xD50202EF60C03EEA.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: loss of speech in speakup when switching between console and gui

Felipe Sateler-2
In reply to this post by Samuel Thibault-8


On Thu, Nov 1, 2018 at 9:42 PM Samuel Thibault <[hidden email]> wrote:
Hello,

(I reordered things a bit to make the story clearer for pulseaudio
maintainers in Cc)

Didier Spaier, le ven. 02 nov. 2018 01:13:09 +0100, a ecrit:
> This message is an answer to the thread started by:
> https://lists.debian.org/debian-accessibility/2018/10/msg00000.html
>
> @Keith: If you don't use pulseaudio, the issue could be an unexpected
> consequence of applying since Thu, 03 May 2018 the patch audio-pause:
> "Pause espeak when the console is switched to a graphical VT"

Well, I believe that report is just another case of the well-known issue
that once pulseaudio is started in X (e.g. for orca), it holds the ALSA
card completely and espeakup can't take it again.  The pause patch makes
espeakup release the ALSA card so that pulseaudio triggered by Orca can
take it. This is considered a better behavior than not getting any audio
inside X just because espeakup holds the ALSA card.

> I then made these changes:
> 1) Edit /etc/pulse/default.pa to append these lines:
> load-module module-alsa-sink device=dmix
> load-module module-alsa-source device=dsnoop

So using dmix is not the default in Debian?

No. Pulseaudio by default does not use dmix, and talks only to "real" hardware. I'm not sure how dmix works, but I don't think that you can use multiple devices (ie, hdmi vs speakers) if you are only interacting with the virtual dmix device.
 

> 2) In /usr/share/alsa, remove the files pukse-alsa.conf and
> alsa.conf.d/alsa.conf, to avoid setting pulseaudio as the default plugin for
> applications using Alsa when pulseaudio is running.

> I made these changes so that applications using pulseaudio and applications
> using alsa directly can nicely coexist, not stepping on each others toes.

> I don't know if the modifications I made are acceptable by the Debian
> authorities though ;)

There is no such thing like "Debian authorities".
There are the maintainers of the pulseaudio stack, which define a
default configuration which aims at the most common case.  I don't know
why dmix is not part of it, that's with them to be discussed, e.g. in a
bug report. Making pulseaudio share the device with alsa thanks to dmix
seems like an option indeed, that you could document on
http://wiki.debian.org/accessibility
I don't know what counterparts there might be to it, again pulseaudio
maintainers will know better.

As mentioned above, pulseaudio allows outputting to multiple devices at the same time.
 

> I also disabled autostarting of pulseaudio at the user level, appending:
> "Hidden=true" to the file /etc/xdg/autostart/pukseaudio.desktop but maybe that
> doesn't matter. Anyway pulseaudio is spawned by the applications that need it.

And notably here by Orca, so I don't think that is involved here.

There are two possible mechanisms for autostarting:

1. systemd --user (the default on linux). You can use `systemctl --user mask pulseaudio.socket pulseaudio.service` to disable pulseaudio.
2. Autospawn (default on non-linux). You can disable it by editing ~/.config/pulse/client.conf (or /etc/pulse/client.conf) and setting autospawn to false.
 

> But these changes were not sufficient to solve the issue so I had a look at the
> speakup Debian package. Seeing the aforementioned patch I thought that it could
> cause the issue. To check I just replaced /usr/bin/espeakup by the binary
> shipped in Slint and it worked.

Ok, so somehow espeakup doesn't manage to take the ALSA card again once
pulseaudio is started in X?  It'd be interesting to check with the patch
(i.e. the Debian binary)

- whether starting espeakup only after running pulseaudio in X works (in
  which case it's the espeakup resume which fails).

Pulseaudio should release the soundcard once you leave your X-session... unless you are already logged in in the target tty. The way this works is that systemd-logind detects which user is "in front of the screen", and grants access to /dev/snd/foo to that user. If you are not logged in the console, then systemd-logind should take away the permissions, and pulseaudio would react accordingly by releasing the device. If you are already logged in in the target console, then systemd-logind will not take away the permissions, so pulseaudio would still keep the device open.
 

- a backtrace of espeakup when it failed to resume, i.e. attach a gdb to
  it and run thread apply all bt full. One such kind of trace was posted
  on http://linux-speakup.org/pipermail/speakup/2018-October/061491.html
  I haven't found the time to really look at it yet, various things have
  kept popping up.

> I understand that you won't be interested by my settings of alsa and pulseaudio
> as you don't use pulseaudio, but this could also solve the issue mentioned in
> the thread "pulseaudio and espeakup" beginning with this message :
> https://lists.debian.org/debian-accessibility/2017/12/msg00089.html

Yes, thus documenting on the wiki, so people can configure it even if
pulseaudio maintainers prefer not to set it by default.

I took a look at the wiki, and it documents running pulseaudio as root. Would that work?

From the pulseaudio side, running pulseaudio in system mode has a few drawbacks:

1. Users can eavesdrop on each other.
2. Any user can DoS others by interfering with pulseaudio.

But it seems to me these drawbacks are not quite avoidable in a a11y scenario? At least not when using dmix?

--

Saludos,
Felipe Sateler
12