pulseaudio and espeakup

[Jude DaShiell]

If pulseaudio actually did what pulseaudio was advertised as doing, 
anything that wanted sound resources would have to go through pulseaudio 
and play nicely with pulseaudio to get those sound resources.  As things 
stand, such is not yet the case.

On Sat, 30 Dec 2017, Sebastian Humenda wrote:

> Date: Sat, 30 Dec 2017 01:52:25
> From: Sebastian Humenda <shumenda at gmx.de>
> To: debian-accessibility at lists.debian.org
> Cc: pkg-pulseaudio-devel at lists.alioth.debian.org
> Subject: Re: pulseaudio and espeakup
> 
> Hi
>
> Samuel Thibault schrieb am 30.12.2017,  1:11 +0100:
>> Incompatibility between Espeakup and Pulseaudio is a recurring issue
> As a side note,  a similar problem occurs with brltty-espeak. Most media players
> will spawn Pulse these days and this leads to BRLTTY not emitting speech
> anymore; the same is true when switching to the graphical console. This is less
> hard to fix, because the user still has the braille display. In any case, the
> issue is the same, both for GUI Pulse usage or media player Pulse usage on the
> command line.
>
>> which AIUI has never actually been settled (or nobody took the time to
>> implement a solution in Debian).
> I don't see how it could work. Ideally Pulse wouldn't grab the audio device, but
> use it along side with other applications. Halim Sahin once proposed to try
> to use ALSA mixing as a Pulse sink
> https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device
> but I haven't found time to actually try it out, because I opted to purge
> Pulseaudio and disable it in all of my applications.
>
>> In summary:
> [?]
> Let me add: BRLTTY can't use Pulse easily, because BRLTTY is a privileged daemon
> and Pulse is (by default) not.
> Would running Pulse as a privileged user help Espeakup? Running Pulse
> system-wide isn't ideal, but it would benefit both GUI and console audio
> applications. I didn't like this setup because it meant that I couldn't access
> boot messages early enough, but we have to make a compromise somewhere.
>
>> - 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).
> Does Espeakup really "take" the device? ALSA does support mixing these days and
> I would be surprised if Espeakup would grab the whole device. That would mean
> that an Espeakup user couldn't listen to audio recordings at the same time.
> Sorry for the nitpicking, but I think that's important here.
>
>> - 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"?
> What exactly is the role of consolekit here?
>
> Sebastian
>

--