[Bug 1991022] Re: Service activation via Systemd socket

[Nathan Teodosio]

** Description changed:

  [Description]
  
  Systemd socket activation for Speech Dispatcher.
  
    - Creates the speech-dispatcher.socket;
    - Modifies the server so that it can detect it was automatically launched by that socket activation; and
    - Modifies the Autotools files accordingly.
  
  [Impact]
  
  It's relevance is described in [1], of which I quote the essential parts
  [my notes in brackets]:
  
  > Sandboxed applications [snaps] that use Speech Dispatcher currently bundle it inside of the sandbox, so that each application has its own "private" instance of Speech Dispatcher running. This works more or less, but it has the downside that speech dispatcher cannot coordinate simultaneous messages from multiple apps. When multiple sandboxed apps use Speech Dispatcher at the same time, the text reading overlaps.
  >
  > In order to solve this issue, I would really like to give sandboxed apps access to the Speech Dispatcher instance of the host.
  
  That can be done by implementing the action of the speech dispatcher
  service via a Systemd socket:
  
  > The only issue I see is having it auto launch. I think it would
  probably be a good step forward for speech-dispatcher to be auto
  launched by a systemd socket like other daemons already do on demand.
  That way the host speech-dispatcher with it's configuration would be
  used by all snaps,
  
  [Additional information]
  
  The changes are already merged upstream[21][22][23], but still not
  released.
  
  I have built and installed the package in Mantic and verified that
  running spd-say from inside a snap causes the host's dispatcher to spawn
  and emit sound — see 'Test case' for more details. This has also been
  verified in Jammy by Lissyx[31][32] and there is a merge proposal[4] for
  the Firefox snap that assumes the incorporation of this delta in speech-
  dispatcher.
  
  Note: Either the installed socket needs to be started manually to
  function correctly or the system needs to be rebooted.
  
  [Test case]
  
  Install the proposed speech-dispatcher and the snap[5] containing spd-
  say. Then,
  
    systemctl start --user speech-dispatcher.socket
    snap run --shell geheim
    $ XDG_RUNTIME_DIR=/run/user/1000 spd-say hi
  
+ should say "hi" through your loudspeakers. If you have no loudspeakers
+ or if you are testing in a virtual machine, you can use Pavucontrol to
+ verify that the dummy output device meter shows activity right after you
+ issue the last command.
+ 
  [Regression potential]
  
  If the socket communication were not working (e.g. connection refused),
  then this would result in text-to-speech failing, even for a not
  sandboxed program.
  
  Do note, however, that if the socket were not available for whatever
  reason (e.g. the user didn't start it manually nor rebooted), then the
  sd_listen_fds(0) >= 1 test would be false and no regression would be
  observed, as then the program would fallback to its usual operation.
  
  [1]  https://github.com/brailcom/speechd/issues/335
  [21] https://github.com/brailcom/speechd/pull/763
  [22] https://github.com/brailcom/speechd/pull/776
  [23] https://github.com/brailcom/speechd/pull/817
  [31]  https://irclogs.ubuntu.com/2023/05/17/%23ubuntu-desktop.html
  [32] https://bugzilla.mozilla.org/show_bug.cgi?id=1729750#c23
  [4]  https://github.com/canonical/firefox-snap/pull/12
  [5]  https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550

** Tags removed: kinetic

** Summary changed:

- Service activation via Systemd socket
+ [SRU] Service activation via Systemd socket

** No longer affects: speech-dispatcher (Ubuntu Focal)

-- 
You received this bug notification because you are a member of
Accessibility, which is subscribed to speech-dispatcher in Ubuntu.
https://bugs.launchpad.net/bugs/1991022

Title:
  [SRU] Service activation via Systemd socket

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1991022/+subscriptions