--
---------- Forwarded message ----------
Date: Sat, 6 Jan 2018 08:45:05
From: Samuel Thibault <sthibault@xxxxxxxxxx>
To: debian-accessibility at lists.debian.org,
pkg-pulseaudio-devel at lists.alioth.debian.org, Scott Leggett <scott at sl.id.au>
Subject: Re: pulseaudio and espeakup
Resent-Date: Sat, 6 Jan 2018 13:50:57 +0000 (UTC)
Resent-From: debian-accessibility at lists.debian.org
Scott Leggett, on sam. 06 janv. 2018 23:47:42 +1100, wrote:
> How about this?
> https://lists.freedesktop.org/archives/pulseaudio-discuss/2010-January/006033.html
Thanks for the pointers!
> the speakup daemons need to be modified so that they can be run as a
> normal user instead of root
I have implemented it in my tree, using basic Unix permissions on
/dev/softsynth*.
> can deal with devices being assigned to them and going away.
It seems promising but I need more details. At which layer does this
happen? Does pulseaudio have hooks for this? I.e. espeakup would provide
hooks for relieving the audio device when pulseaudio feels the need to?
It seems to me that it's the kind of approach which would work.
> a little wrapper for the speakup daemons that sets up a
> pseudo-session in ck that owns the console and then runs the speakup
> daemon in it.
That can't work.
espeakup is not a screen reader that lives within a session like orca
does, for the simple reason that one needs it *before* logging in. In X,
one copes with it by having a lightdm/gdm user running the logging
session. In the console, there is no such thing, getty is running as
root.
Actually espeakup is not even a screen reader, the actual screen reading
happens in the kernel, and espeakup is just a deamon which basically
reads text from /dev/softsynthu and uses the audio card to synthesize
it. espeakup should be fine with the card being taken away, because it
probably means that the console got switched to some X session, and thus
the in-kernel screen reader won't have anything to say anyway.
Samuel
