On Thu, Nov 1, 2018 at 9:42 PM Samuel Thibault <sthiba...@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
