Editing System-wide speakup

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 26: Line 26:
# Linux boots  
# Linux boots  
# systemd gives root the current audio device
# systemd gives root the current audio device
# systemd starts espeakup as root
# systemd starts starts espeakup as root
# You can read the login prompt or login as root
# You can read the login prompt or login as root
# You log in as your own user
# You log in as your own user
Line 56: Line 56:


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.
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 ===
=== Running espeakup as your user ===
Line 81: Line 79:
This will cause the speakup kernel modules to load at boot.
This will cause the speakup kernel modules to load at boot.


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


  --- PASTE START ---
  --- PASTE START ---
Line 99: Line 97:
  [Unit]
  [Unit]
  Description=Software speech output for Speakup
  Description=Software speech output for Speakup
After=pulseaudio.service
  [Service]
  [Service]
  Environment="default_voice= ALSA_CARD="
  Environment="default_voice= ALSA_CARD="
Line 107: Line 104:
  OOMScoreAdjust=-900
  OOMScoreAdjust=-900
  [Install]
  [Install]
After=pulseaudio.service
  WantedBy=default.target
  WantedBy=default.target
  --- PASTE END ---
  --- PASTE END ---
Line 114: Line 112:
Change <code>pulseaudio.service</code> to <code>pipewire.service</code> if you're using on PipeWire.
Change <code>pulseaudio.service</code> to <code>pipewire.service</code> if you're using on PipeWire.


Step 4: Run these commands in a terminal as your user:
Step 4: Run these commands:


  --- PASTE START ---
  --- PASTE START ---
Line 128: Line 126:
# Add your user to the audio group
# Add your user to the audio group


Step 5: Reboot and enjoy!
Step 5: Reboot and run espeakup as your user.


There's two downsides to this method:
There's two downsides to this method:


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


Line 138: Line 136:
There are some ideas I've considered to solve this problem.
There are some ideas I've considered to solve this problem.


=== Loaning PulseAudio to root ===
=== Locking PulseAudio after boot ===
The main case here would be to allow root to use a user's PulseAudio install.
TODO: ...
 
=== Sharing Speakup ===
- logind can proxy/share fds


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.
- have a proxy that sits between speakup and espeak


I'm not too sure what this buys compared to using sudo or something to act as root.
- send messages to espeakup instances based on current active UID


In practice I'm not sure how easy this would be to implement. You would need to replace the logind hardware management for sound with something else that allows finer grained management of hardware.
- 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
=== Sharing Speakup between multiple users ===
Things would be a lot easier if we could run one espeakup instance per user. This is tricky because the Speakup kernel modules don't have concepts of users or sessions.


There's a wide list of engineering problems to solve with this:
- have a shim that blocks pulseaudio from starting until it has permission, but also don't consume the buffer


* Saving and restoring per-user Speakup settings
i do not like how i'm basically reinventing flow control but poorly
* Saving and restoring the softsynth state between users
* Proxying /dev/softsynth so users can't read other's data
* Restricting access to the fakekey input device
* Handling graceful handovers from ALSA to PulseAudio
* Handling forceful handovers from PulseAudio to ALSA
* Shim PulseAudio so it waits for hardware access before running
* Flow control to indicate when the proxy is ready to send
* Flow control to indicate when espeakup is ready to talk
* Buffering data when espeakup isn't ready
* Discarding buffered data when speakup signals espeakup to shut up
* Handling messages sent back from espeakup to speakup and flow control for that


There's a lot to untangle here since we're touching multiple levels of abstraction.
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 between multiple users ===
=== Sharing espeakup ===
A more practical solution might be to run a root espeakup instance and proxy its PCM output to users.  
so this makes the only viable solution to send PCM data from a root espeakup instance.


This would cut down the engineering problems to:
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


* Assigning /sys/accessibility/speakup to the current seat
=== Loaning PulseAudio to root ===
* Proxying PCM data to stub programs users run
- the main case here is with root who doesn't have a pulseaudio setup
* Handling graceful handovers from ALSA to PulseAudio
* Shim PulseAudio so it waits for hardware access before running
* Flow control to indicate when a proxy is ready to send
* Buffering data when a stub isn't playing audio
* Discarding buffered data when espeakup wants to shut up


This gives most the benefits of sharing speakup but without saving or restoring state.
- doesn't solve sharing speakup but maybe things could take turns?
[[Category:Research]]
Please note that all contributions to JookWiki are considered to be released under the Creative Commons Zero (Public Domain) (see JookWiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)