loss of speech in speakup when switching between console and gui

Tue Nov 6 23:44:41 GMT 2018

On Thu, Nov 1, 2018 at 9:42 PM Samuel Thibault <sthibault at debian.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pulseaudio-devel/attachments/20181106/f6accd7a/attachment-0001.html>