System-wide speakup: Difference between revisions

From JookWiki
(→‎Sharing Speakup: Start writing)
(→‎Loaning PulseAudio to root: Mention sudo better)
Line 143: Line 143:
This would have mean that multiple people can privately use a computer, with the exception of one user being able to read root's screen.
This would have mean that multiple people can privately use a computer, with the exception of one user being able to read root's screen.


I'm not too sure what this buys outside using sudo.
I'm not too sure what this buys compared to using sudo or something to act as root.
=== Sharing Speakup between multiple users ===
=== Sharing Speakup between multiple users ===
Things would be a lot easier if we could run one speakup instance per user. This is tricky because the Speakup kernel modules don't have concepts of users or sessions.
Things would be a lot easier if we could run one speakup instance per user. This is tricky because the Speakup kernel modules don't have concepts of users or sessions.

Revision as of 20:24, 12 October 2022

Is it possible to use Speakup across multiple users on Linux? This article is the notes and ramblings of someone who tries to do that.

Background

The Linux kernel includes the Speakup screen reader. Unlike most desktop screen readers, Speakup will aid in reading the Linux virtual TTYs that you can switch to with Ctrl+Alt+F1 through Ctrl+Alt+F6 on most systems.

This functionality is vitally important for troubleshooting in a Linux system and running command line applications, which is unfortunately one of the more accessible experiences on Linux.

Speakup alone is not enough to implement a screen reader: It still needs some speech synthesizer to turn text and control signals in to audio. Once upon a time hardware synthesizers connected over serial were used to do this task, but as computers became more capable software synthesizers became viable.

Speakup supports software synthesizers by exposing a character device in /dev/softsynthu. A connector such as connects to this device and implements the synthesizer protocol and handles playback of speech. In practice the software synthesizer is espeakup which plays speech using eSpeak NG.

The problem

Linux is a multi-user system, but hardware and other resources are not. There's only one sound card and only one Speakup device. So these resources have to be shared somehow.

Since around 2007 with the release of ConsoleKit the Linux desktop has handled sharing resources using the idea of seats. To put it simply:

  • Devices get allocated to seats
  • Logging in gives you a session
  • Only one session can use a seat at a time
  • Switching sessions requires handing over devices to another session

The Speakup device has no support for sharing, but the sound card does.

This leads to the following situation:

  1. Linux boots
  2. systemd gives root the current audio device
  3. systemd starts starts espeakup as root
  4. You can read the login prompt or login as root
  5. You log in as your own user
  6. systemd gives your user the current audio device
  7. Your PulseAudio instance claims the device
  8. The root espeakup can no longer speak
  9. You can no longer use Speakup
  10. You might have no sound at all if PulseAudio couldn't claim the device if espeakup was still talking while PulseAudio was starting
  11. You switch to another TTY using Ctrl+Alt+F2
  12. systemd gives root the current audio device
  13. Your PulseAudio instance frees the device
  14. espeakup can talk again using the sound card

Because espeakup can only speak when root is using the current seat effectively becomes useless outside logging in as root on your computer.

It's also important to note that PulseAudio stores settings for volume and outputs. You might be using Bluetooth headphones at low volume but then switch to a root TTY and have espeakup blare loudly out your desktop speakers.

It really makes me wonder why PulseAudio doesn't have a per-seat instance that lets you switch between sessions and preserves audio configuration but still swaps out which user's applications can use audio.

As a quick note: PipeWire has the exact same behaviour, so for the most part you can substitute 'PulseAudio' with 'PipeWire' or any sound other server when reading this page.

Existing solutions

Here are some solutions that kind of work but have severe trade-offs.

Running PulseAudio system-wide

Running system-wide PulseAudio allows you to always have espeakup running and talking regardless of who is currently logged in.

However this has a major security concern, mainly that all users can now play and record audio from your sound card and other applications. For more information see What is wrong with system mode?

Running PipeWire system-wide is a little more complicated: You need to run both the PipeWire daemon and a session manager system-wide. This session manager needs to lock hardware and not give it up on seat switch.

I'm not going to include instructions on how to do this as I can't provide support for it. Sorry.

Running espeakup as your user

It's possible to run espeakup as your own user by:

  • Taking control of the audio device away from logind
  • Giving control of all audio devices to your user
  • Giving control of the softsynth to your user
  • Running espeakup as a daemon as your user
  • Running espeakup at boot as your user

I've prepared steps to follow to get this working below.

Paste lines between --- PASTE START --- and --- PASTE END --- in to the file specified or a terminal.

Step 1: Put this in /etc/modules-load.d/speakup.conf

--- PASTE START ---
speakup
speakup_soft
--- PASTE END ---

This will cause the speakup kernel modules to load at boot.

Step 2: Put this in /etc/udev/rule.d/99-speakup.conf

--- PASTE START ---
SUBSYSTEM=="sound", TAG-="seat", GROUP="audio"
KERNEL=="softsynth*", GROUP="audio"
--- PASTE END ---

This will will do three things:

  1. Stop logind managing sound devices
  2. Give users in the audio group access to sound devices
  3. Give users in the audio group access to Speakup

Step 3: Put this in ~/.config/systemd/user/espeakup.service

--- PASTE START ---
[Unit]
Description=Software speech output for Speakup
[Service]
Environment="default_voice= ALSA_CARD="
ExecStart=/usr/bin/espeakup -d --default-voice=${default_voice}
Restart=always
Nice=-10
OOMScoreAdjust=-900
[Install]
After=pulseaudio.service
WantedBy=default.target
--- PASTE END ---

This is a service that just runs the espeakup daemon. It is set to start after pulseaudio.

Change pulseaudio.service to pipewire.service if you're using on PipeWire.

Step 4: Run these commands:

--- PASTE START ---
systemctl --user enable espeakup
loginctl enable-linger
sudo gpasswd -a $USER audio
--- PASTE END ---

This does three things:

  1. Enable the speakup user service
  2. Enable running user services when logged out
  3. Add your user to the audio group

Step 5: Reboot and run espeakup as your user.

There's two downsides to this method:

  1. Your user can see what other users are reading, including root
  2. Other users can't play audio

Ideas

There are some ideas I've considered to solve this problem.

Loaning PulseAudio to root

The main case here would be to allow root to use a user's PulseAudio install.

This would have mean that multiple people can privately use a computer, with the exception of one user being able to read root's screen.

I'm not too sure what this buys compared to using sudo or something to act as root.

Sharing Speakup between multiple users

Things would be a lot easier if we could run one speakup instance per user. This is tricky because the Speakup kernel modules don't have concepts of users or sessions.

- speakup fakekey

- logind can proxy/share fds

- have a proxy that sits between speakup and espeak

- send messages to espeakup instances based on current active UID

- during a switch between instances, wait for the current instance to finish talking OR the stop talking control is sent. then start feeding the new instance data

- have a shim that blocks pulseaudio from starting until it has permission, but also don't consume the buffer

i do not like how i'm basically reinventing flow control but poorly

ok so it turns out i was WRONG: you can't share speakup protocol between multiple synths! the protocol is stateful! ie if you tell it to change voice and switch synth the voice change won't be applied. YAY

Sharing espeakup output

An easier solution might be

so this makes the only viable solution to send PCM data from a root espeakup instance.

on top of that this also means i have to modify espeakup to handle some flow control AND output to a buffer instead of the sound card