Jude DaShiell here. On archlinux I have removed pulseaudio entirely
since once installed pulseaudio works correctly for a random number of
hours and then while a system is running with output going to speakers
suddenly the speaker output has heavy static added to it which is the
pink noise you hear when running speaker-test. The pink noise is at
such a level as to make use of pre-existing output impossible. Running
pulseaudio -k fails to clear this problem and a power down and reboot of
the computer also fails to clear this problem. For that reason I had to
remove pulseaudio and all required and optional dependencies from the
archlinux system then reboot the computer in order to get speech back.
I've let pulseaudio-discuss@xxxxxxxxxxxxxxx know about this situation.
For this reason, I consider pulseaudio a bad actor and until I can find
out how to run pulseaudio in such a way where it logs changes with time
stamps to its own log file so when this happens again maybe me or
someone else can locate these changes in that log and send the failure
output to pulseaudio-discuss for their debugging it's not safe or
reliable to use pulseaudio any longer. This has happened to me on
archlinux and I'd be interested in hearing from anyone else experiencing
similar difficulties with pulseaudio along with operating system used
and version and which version of pulseaudio was in use when it happened
too. I can forward this information along to pulseaudio-discuss since I
was given an email list membership on pulseaudio-discuss.
On Sat, 6 Jan 2018, Linux for blind general discussion wrote:
Date: Fri, 5 Jan 2018 18:12:12
From: Linux for blind general discussion <blinux-list@xxxxxxxxxx>
To: blinux-list@xxxxxxxxxx
Subject: Re: slint14.2.1 released
Hello,
Le 05/01/2018 ? 19:36, Linux for blind general discussion a ?crit?:
Jude Dashiell here. I have an idea how to keep console speech high
quality and still have orca start up normally when the graphical user
environment starts. The client.conf file in /etc/pulseaudio/ could be
copied to client.conf.gue and also copied to client.conf.txt once
spawn is set to no on line 25. The client.conf.gue file would have
spawn set to yes. When startx is run, have
/etc/pulseaudio/client.conf overwritten with client.conf.gue and this
is before the actual graphical user environment starts running. The
problem with this for those starting in console mode after having used
graphical mode will be the client.conf file is back to bug status
situation. If rc.local could be used to unambiguously overwrite
client.conf with client.conf.txt before speech came up that would
partly solve this problem. The problem would come about for people
starting up in graphical user environment unless a variable could be
found with either console or graphical in it to test inside rc.local
and if that were the case and someone started up in graphical mode
copy client.conf.gue to client.conf unambiguously, so a conditional
copy would happen inside of rc.local.
Thanks for your suggestions. I will study them carefully and also
probably consider specific settings at the user level user depending on
user's needs, as "man pulse-client.conf" states:
cut here
The PulseAudio client library reads configuration directives from a
configuration file on startup. If the per-user file
~/.config/pulse/client.conf exists, it is used, otherwise the system
configuration file /etc/pulse/client.conf is used.
cut here
This seems like an opportunity to allows some flexibility.
I have also found other interesting ideas like e.g. on ArchWiki:
https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_as_a_minimal_unintrusive_dumb_pipe_to_ALSA
I should be possible to complete the program login-chooser, performing
different audio settings for text versus graphical login, as a way of
implementing the idea you just stated.
Testing locally will take several days, stay tuned.
Greetings,
Didier
http://slint.fr
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list
--
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list