Hi Janina, Le 05/07/2018 à 11:05, Janina Sajka a écrit :
Synopsis: Your advice works, but there are issues, mostly with espeakup. I've left them here for completeness. With your permission I'll repost that section to the Speakup list.
No problem. I saw your post there and just registered. I will answer the problem you list as much as I can.
1. The post installation guidance printed to screen by espeakup-git install is not working for me. Enabling espeakup@user does nothing. In order to get speech output, I have to enable espeakup explicitly, and sometimes run a 'sudo systemctl restart espeakup' after logging in.
I am not acquainted with systemd but I assume that setting the service that starts espeakup after booting is more in the scope of systemd than of espeakup proper. Let me quote the README file in the source archive of espeakup: <quoting begins below> Starting Up =========== This program should be run after speakup is set up to communicate with a software synthesizer and after /dev/softsynth exists. The way this is done is distribution specific, so it is beyond the scope of this documentation. <quoting ended above> So, in your case this issue should be brought to the Arch packagers, I think. For your information in Slint the attached script rc.espeakup is used to manage the espeakup daemon. I assume that when using systemd "sudo systemctl start espeakup" is roughly equivalent to "/etc/rc.d/rc.espeakup start" and so on.
2. I discovered systemctl start speakupconf is assuming an /etc/speakup directory with relevant data. I had to puruse journalctl to discover this. Shouldn't this be checked on speakupconf install?
I can't help much there either, as this is also distribution specific. I think that Storm Dragon (the maintainer of the PKGBUILD for espeakup) could be a lot more helpful than me, and maybe also Peter Vágner All I can say is that in Slint we use a configuration file (also attached) /etc/espeakup.conf, but I am afraid that won't help. Please note that we don't provide settings at the user level, only system wide ones. I would be curious to know how Arch does.
2. espeakup-git is honoring the default card directive in * /etc/asound.conf. This is new. The shipping espeakup, as all * previous incarnations, simply chose the first available audio * card. I need my Speakup device to be different from the alsa * default. This is a problem for me, though I can live with it for * the moment.
This change is not in espakup-git that doesn't deal with sound at all, rather probably in the alsa library or more generally in the audio backend of espeak-ng (can be pcaudiolib too)
3. Setting /etc/asound.conf to default card 0 loads a totaly * unusable speakup. Screen review on the numpad is quite broken, * especially 4-5-6 and 1-2-3 (word and char) review. Also, speech * is NOT immediately silenced by Keypad-Enter or Ctrl. CARD 0 is * the onboard HDA Intel audio device.
4. Resetting the default in /etc/asound.conf to CARD 2 fixes much * of the problem in 3. above. CARD 2 is a Sennheiser headset * device that I intend for making SIP calls, but both linphone and * freeswitch are currently broken on Arch, so this is the * configuration I've temporarily resumed using. Screen review * works as expected here, but silencing speech is still an issue. * Also, a spurious "space" is read with 7-8-9 and after pressing * Enter on a command. 5. In both cases, both speech-dispatcher and espeakup, my cards are blocked to other output, i.e. no dmix. This is new. The shipping espeakup was not giving me this problem, though I cannot compare for previous speech-dispatcher as I didn't try to use that device for other output.
Issues 3, 4 and 5 are klinked to sound setting (alsa?) and are not to espeakup. This is also distribution specific and I can't help there. I'd look at a possible change in alsa or in another audio backend of speech-dispatcher in such a case. For your information I am happy with these two lines in /etc/pulse/default.pa: load-module module-alsa-sink device=dmix load-module module-alsa-source device=dsnoop but that's really a shot in the dark.
6. I should note that I have espeak-ng on two machines. The problems resolved in this thread were from my main desktop X86_64 system. I have previously successfully installed Arch toa USB3 flash drive for booting a 2013 vintage Apple Airbook. Until the update just this week to the latest Arch 4.17.2 kernel, plus whatever audio drivers came with that update, the problems with espeakup-git mentioned above were NOT visible on the Apple, except for the reading of the spurious "space" char. However, the Apple is similarly broken now. Something in very recent updates has broken things badly it seems. Not sure what. I can say more on Orca on the Airbook, but I have only launched it once so far.
No clue for that, sorry. Feel free to quote this post in the speakup mailing list if you think that can help you get more help from there. Best regards, Didier
Attachment:
rc.espeakup
Description: Text document
Attachment:
espeakup.conf
Description: Text document
Attachment:
0xD50202EF60C03EEA.asc
Description: application/pgp-keys