pulseaudio problems

[Jude DaShiell]

Probably pulseaudio could do better garbage collection and better buffer 
memory buffer management.  I can listen to rather long multimedia files 
and sooner or later get complete static with the playing of the file 
cutting out.  Rebooting the computer does nothing to disrupt this static, 
at that point, espeakup no longer works.  Earlier I've been running 
speaker-test then rebooting to get speech back, but I think I'll use 
pulseaudio -k when this happens next time and see if that works better.  I 
run emacspeak with emacs out of a script and routinely shut off espeakup 
before running emacs then turn espeakup back on after finishing with 
emacs and emacspeak.  I put a pulseaudio -k command in the bottom of the 
script and will test its performance later today.  If it works, strangled 
speech with heavy static overlay will no longer be a problem here.




--

Re: pulseaudio and espeakup

[Alex ARNAUD]

Le 30/12/2017 à 01:11, Samuel Thibault a écrit :

- 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.


Only PulseAudio could emits sound at the same time. A possible solution 
could be to enable to emit sound from TCP or Unix socket as described 
here: http://billauer.co.il/blog/2014/01/pa-multiple-users/


What do you think about this solution?
It seems it's not only a accessibility issue because a computer could be 
used by multiple users and in some situations sighted users encounter 
this problem also.



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.


I'm not sure removing PulseAudio is a good idea. As I understand New 
Firefox releases require PulseAudio to emit sound.



We really need to fix this (and I'm really depressed that it seems
nobody took the time to manage to work out a solution).


I agree with you on this particular point but you couldn't miss the 
contribution of Paul and Jeremy on accessibility team on packaging that 
could allow you to focus on more complicated tasks you seems to be aware of.


Best regards.--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Re: 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 
To: debian-accessibility@lists.debian.org
Cc: pkg-pulseaudio-de...@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



--