slint14.2.1 released

Sat Jan 6 02:02:42 UTC 2018

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 at freedesktop.org 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 at redhat.com>
> To: blinux-list at redhat.com
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list

-- 