mastodon - Link to source
#linux #accessibility question: How the heck do I actually use `espeakup`? I have it running as a system service but I'm not sure how to make it do anything. e.g. I don't hear anything when it starts and my terminals aren't reacting any different. The man page is very sparse without any guide on how I'm supposed to actually use it.
#Accessibility #linux
in reply to Mauve 👁💜
mastodon - Link to source

bscross32

eSpeakup is the bridge between Speakup and eSpeak. If you don't have one or the other, nothing will happen when you log in via shell or drop to shell. Also, it's been a while, but I think it only works on eSpeak, not eSpeakNG.

As an alternative, you might try Fenrir, which is an entire shell screen reader written in Python.

in reply to bscross32
mastodon - Link to source

Mauve 👁💜

@bscross32 TY! It seems arch linux doesn't have "speakup" in their package manager. Must have misunderstood something somewhere.

I still haven't had luck getting fenrir to work. Could it be due to me using wayland as the "top level" window manager instead of the default linux terminal emulator? 😅 It starts, and it seems to capture Fenrir+H, but it's not reading my terminals.

@bscross32
in reply to Mauve 👁💜
mastodon - Link to source

Elijah Massey

@bscross32 Yes, using Wayland is exactly the problem. Speakup only works on the plain virtual terminal, and it will not work under X or Wayland. Speakup is a kernel module (so no package is necessary for it because it is in the Arch kernel), and espeakup is the program that connects to speakup on /dev/softsynth and speaks its output using eSpeak NG. Just make sure you are on a real virtual terminal (plain TTY), make sure the speakup_soft module is loaded, and start the espeakup service, and it should work. Also make sure sound can play as root. If you use Pipewire or PulseAudio, you may have to do some work for that, but if you use plain ALSA, it should be fine. Personally I use speechd-up instead, because even though it hasn't been maintained in many years, I still prefer it because it uses Speech Dispatcher instead of directly using eSpeak NG, meaning its a lot easier to increase the maximum speech rate, and I can use Pipewire and run Speech Dispatcher as my user, run speechd-up as root, and point it to the Speech Dispatcher socket for my user with the SPEECHD_ADDRESS environment variable, so I can still use Pipewire with Bluetooth audio and its other advantages, and still use speakup.
@bscross32
in reply to Elijah Massey
mastodon - Link to source

Mauve 👁💜

@emassey0135 Good to know thank you! I use speech-dispatcher in other contexts so speechd-up is interesting. Is it strictly necessary to run it as root? Do you have your configs published somewhere by any chance?
@Elijah Massey
in reply to Mauve 👁💜
mastodon - Link to source

Elijah Massey

Perhaps you could make a udev rule that changes the permissions of /dev/softsynth so you don't have to run it as root. Then you could create a Systemd user service for it. The difficult part with this is making it work on the login prompt. I think if you run "loginctl enable-lingering <your-user>" that might work, and add yourself to the audio group if you use Pipewire. Actually that might end up being more reliable then running it as root, because when I run it as root and make it use my user's Speech Dispatcher, there is no way to make it depend on it that I've found, so it often doesn't work at the login prompt and I have to restart the service manually. Although maybe I could make it depend on the socket file existing, since I already have my user's Speech Dispatcher running as a daemon with no timeout instead of using auto-spawn. But running it as your user and not as root might still be better because then auto-spawn might actually work so you wouldn't need to worry about adding an explicit dependency or making Speech Dispatcher run as a daemon. i have not published my configs, but I could look into running speechd-up as my user instead of root and see if it works and let you know what I did.
in reply to Elijah Massey
glitchsoc - Link to source

Quin

@emassey0135 And this, right here, perfectly sums up why my Linux workflow has been for years, and likely will remain so for at least another decade, using a Windows machine with ssh and samba. Well, before I switched to a physical linux box I just used WSL's built-in WSL$ environment variable instead of samba, but headless linux boxes without any audio are how I've done most of my work in the past few years. But I refuse to touch Linux audio. And this whole reply...perfectly sums up why, haha. It's insanely impressive you've figured that out, but you should not have had to.
@Elijah Massey

Johann reshared this.

in reply to Quin
mastodon - Link to source

Elijah Massey

@TheQuinbox True, I think a good NixOS flake could solve a lot of this though. Or even just better default configurations with all of this set up on most distributions, although you pretty much expect Arch Linux to require you to configure everything yourself. But for other distributions like Ubuntu and Fedora that are supposed to be easy to use and already set up, they could just set all this up so you have console speech by default if you enable Orca on the desktop.
@Quin
in reply to Elijah Massey
friendica (DFRN) - Link to source

Peter Vágner

@Elijah Massey @Quin @Mauve 👁💜 The thing is most people think machine wide services and user sharing of audio are security issues. This is one reason why it's left for end users.
With pipewire it's possible to configure your user specific daemon to expose a pulse server running either on an unix socket or on loopback address and then root instance of espeakup or speechdup can be instructed to speak through that server. That's essentially allowing the same thing i.e. user graphic session and virtual tty audio playing at the same time.
And also it does not matter if running under X or wayland, audio device sharing between users is the issue I would say.
There is a discussion with some tips on how to achieve this with pipewire here in the @Arch Linux forum bbs.archlinux.org/viewtopic.ph…
@Arch Linux @Mauve 👁💜 @Quin @Elijah Massey
in reply to Mauve 👁💜
mastodon - Link to source

Elijah Massey

Another thing to be aware of is that when you compile speechd-up, you have to make a change to one of the C files because there is a compilation error. It is a very small change though. You also have to run "make speechd-up" instead of just "make", because the info documentation is broken for some reason. Here's the repository I get it from: github.com/williamh/speechd-up

GitHub - williamh/speechd-up: interface between Speech Dispatcher and Speakup

interface between Speech Dispatcher and Speakup. Contribute to williamh/speechd-up development by creating an account on GitHub.
GitHub