<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 1, 2018 at 9:42 PM Samuel Thibault <<a href="mailto:sthibault@debian.org" target="_blank">sthibault@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
(I reordered things a bit to make the story clearer for pulseaudio<br>
maintainers in Cc)<br>
<br>
Didier Spaier, le ven. 02 nov. 2018 01:13:09 +0100, a ecrit:<br>
> This message is an answer to the thread started by:<br>
> <a href="https://lists.debian.org/debian-accessibility/2018/10/msg00000.html" rel="noreferrer" target="_blank">https://lists.debian.org/debian-accessibility/2018/10/msg00000.html</a><br>
> <br>
> @Keith: If you don't use pulseaudio, the issue could be an unexpected<br>
> consequence of applying since Thu, 03 May 2018 the patch audio-pause:<br>
> "Pause espeak when the console is switched to a graphical VT"<br>
<br>
Well, I believe that report is just another case of the well-known issue<br>
that once pulseaudio is started in X (e.g. for orca), it holds the ALSA<br>
card completely and espeakup can't take it again.  The pause patch makes<br>
espeakup release the ALSA card so that pulseaudio triggered by Orca can<br>
take it. This is considered a better behavior than not getting any audio<br>
inside X just because espeakup holds the ALSA card.<br>
<br>
> I then made these changes:<br>
> 1) Edit /etc/pulse/<a href="http://default.pa" rel="noreferrer" target="_blank">default.pa</a> to append these lines:<br>
> load-module module-alsa-sink device=dmix<br>
> load-module module-alsa-source device=dsnoop<br>
<br>
So using dmix is not the default in Debian?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 2) In /usr/share/alsa, remove the files pukse-alsa.conf and<br>
> alsa.conf.d/alsa.conf, to avoid setting pulseaudio as the default plugin for<br>
> applications using Alsa when pulseaudio is running.<br>
<br>
> I made these changes so that applications using pulseaudio and applications<br>
> using alsa directly can nicely coexist, not stepping on each others toes.<br>
<br>
> I don't know if the modifications I made are acceptable by the Debian<br>
> authorities though ;)<br>
<br>
There is no such thing like "Debian authorities".<br>
There are the maintainers of the pulseaudio stack, which define a<br>
default configuration which aims at the most common case.  I don't know<br>
why dmix is not part of it, that's with them to be discussed, e.g. in a<br>
bug report. Making pulseaudio share the device with alsa thanks to dmix<br>
seems like an option indeed, that you could document on<br>
<a href="http://wiki.debian.org/accessibility" rel="noreferrer" target="_blank">http://wiki.debian.org/accessibility</a><br>
I don't know what counterparts there might be to it, again pulseaudio<br>
maintainers will know better.<br></blockquote><div><br></div><div>As mentioned above, pulseaudio allows outputting to multiple devices at the same time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I also disabled autostarting of pulseaudio at the user level, appending:<br>
> "Hidden=true" to the file /etc/xdg/autostart/pukseaudio.desktop but maybe that<br>
> doesn't matter. Anyway pulseaudio is spawned by the applications that need it. <br>
<br>
And notably here by Orca, so I don't think that is involved here.<br></blockquote><div><br></div><div>There are two possible mechanisms for autostarting:</div><div><br></div><div>1. systemd --user (the default on linux). You can use `systemctl --user mask pulseaudio.socket pulseaudio.service` to disable pulseaudio.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> But these changes were not sufficient to solve the issue so I had a look at the<br>
> speakup Debian package. Seeing the aforementioned patch I thought that it could<br>
> cause the issue. To check I just replaced /usr/bin/espeakup by the binary<br>
> shipped in Slint and it worked.<br>
<br>
Ok, so somehow espeakup doesn't manage to take the ALSA card again once<br>
pulseaudio is started in X?  It'd be interesting to check with the patch<br>
(i.e. the Debian binary)<br>
<br>
- whether starting espeakup only after running pulseaudio in X works (in<br>
  which case it's the espeakup resume which fails).<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- a backtrace of espeakup when it failed to resume, i.e. attach a gdb to<br>
  it and run thread apply all bt full. One such kind of trace was posted<br>
  on <a href="http://linux-speakup.org/pipermail/speakup/2018-October/061491.html" rel="noreferrer" target="_blank">http://linux-speakup.org/pipermail/speakup/2018-October/061491.html</a><br>
  I haven't found the time to really look at it yet, various things have<br>
  kept popping up.<br>
<br>
> I understand that you won't be interested by my settings of alsa and pulseaudio<br>
> as you don't use pulseaudio, but this could also solve the issue mentioned in<br>
> the thread "pulseaudio and espeakup" beginning with this message :<br>
> <a href="https://lists.debian.org/debian-accessibility/2017/12/msg00089.html" rel="noreferrer" target="_blank">https://lists.debian.org/debian-accessibility/2017/12/msg00089.html</a><br>
<br>
Yes, thus documenting on the wiki, so people can configure it even if<br>
pulseaudio maintainers prefer not to set it by default.<br></blockquote><div><br></div><div>I took a look at the wiki, and it documents running pulseaudio as root. Would that work?</div><div><br></div><div>From the pulseaudio side, running pulseaudio in system mode has a few drawbacks:</div><div><br></div><div>1. Users can eavesdrop on each other.</div><div>2. Any user can DoS others by interfering with pulseaudio.</div><div><br></div><div>But it seems to me these drawbacks are not quite avoidable in a a11y scenario? At least not when using dmix?</div></div><div><br></div>-- <br><div dir="ltr" class="m_7193402625166823498gmail_signature"><br>Saludos,<br>Felipe Sateler</div></div></div>