--
---------- Forwarded message ----------
Date: Sat, 6 Jan 2018 07:47:42
From: Scott Leggett <scott@xxxxxxxx>
To: pkg-pulseaudio-devel at lists.alioth.debian.org,
debian-accessibility at lists.debian.org
Subject: Re: pulseaudio and espeakup
Resent-Date: Sat, 6 Jan 2018 12:54:18 +0000 (UTC)
Resent-From: debian-accessibility at lists.debian.org
On 2017-12-30.01:11, Samuel Thibault wrote:
> Incompatibility between espeakup and pulseaudio is a recurring issue
> which AIUI has never actually been settled (or nobody took the time to
> implement a solution in Debian).
Yes, one bug tracking this is #864829.
> - currently espeakup runs as root, and then takes over the ALSA device.
> orca inside lightdm or gdm then can't emit its output (unless by luck
> espeakup didn't say anything at boot, and then pulseaudio inside the
> lightdm/gdm session manages to get the device, but then it's espeakup
> which can't get the device).
>
> - espeakup could be made to run as normal user, but then it seems its
> pulseaudio server can't access audio, I guess that's because consolekit
> doesn't consider it to be running "on the console"?
>
> - espeakup and lightdm/gdm could be given audio group access, but then
> there are two competing pulseaudio servers, and only the first one seems
> to actually manage to emit sound.
>
> In the end, I have no idea how this situation is supposed to work, and
> for now I have just made the espeakup d-i script *purge* pulseaudio,
> to get things working. Of course I can see various documentations
> saying one could use a system-mode daemon, but upstream doesn't want
> that. Normally, espeakup could have its own pulseaudio server, playing
> well along pulseaudio servers of other users, but I failed to get
> something working.
>
> Any thoughts?
How about this?
https://lists.freedesktop.org/archives/pulseaudio-discuss/2010-January/006033.html
--
Regards,
Scott.
