| 2022-09-27 22:16:51 |
Nathan Teodosio |
bug |
|
|
added bug |
| 2022-09-27 22:16:51 |
Nathan Teodosio |
attachment added |
|
speechd-sbuild-log https://bugs.launchpad.net/bugs/1991022/+attachment/5619593/+files/speechd-sbuild-log |
|
| 2022-09-27 22:17:02 |
Nathan Teodosio |
tags |
|
wip |
|
| 2022-09-27 22:17:09 |
Nathan Teodosio |
tags |
wip |
kinetic wip |
|
| 2022-09-28 11:12:51 |
Nathan Teodosio |
description |
[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.
[Rationale]
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.
And then,
> 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 change was already proposed upstream[2], but it is on hold because the build with undefined sanitizer CI failed two times out of four. In the words of the maintainer,
> That's not systematic, but that's often enough that it'll be a pain in the CI, and is a sign of some subtle bug creeping in there.
I then opened my own fork with debugging enabled[3] to track down the problem, but the CI succeeded all the six times I executed it[4], so at this point I'd assume it was a transient issue more than a subtle bug.
I have built and installed the package in Kinetic and verified that spd-say still causes the dispatcher spawn and emits sound. Upstream test can also confirm this.
[1]: https://github.com/brailcom/speechd/issues/335
[2]: https://github.com/brailcom/speechd/pull/763
[3]: https://github.com/brailcom/speechd/commit/a63a5f7fe187edd5bf60c12a9c8e078cd2234e73
[4]: https://github.com/nteodosio/speechd/actions/runs/3129483607 |
[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.
[Rationale]
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.
And then,
> 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[2], but still not released.
I have built and installed the package in Kinetic and verified that spd-say still causes the dispatcher spawn and emits sound. Upstream test can also confirm this.
[1]: https://github.com/brailcom/speechd/issues/335
[2]: https://github.com/brailcom/speechd/pull/763 |
|
| 2022-09-28 11:15:09 |
Nathan Teodosio |
attachment added |
|
0.11.3-1--0.11.3-1ubuntu1.diff https://bugs.launchpad.net/bugs/1991022/+attachment/5619783/+files/0.11.3-1--0.11.3-1ubuntu1.diff |
|
| 2022-09-28 11:15:09 |
Nathan Teodosio |
attachment added |
|
speechd-apt-install-log https://bugs.launchpad.net/bugs/1991022/+attachment/5619784/+files/speechd-apt-install-log |
|
| 2022-09-28 11:16:26 |
Nathan Teodosio |
tags |
kinetic wip |
kinetic |
|
| 2022-09-28 11:16:53 |
Nathan Teodosio |
bug |
|
|
added subscriber Ubuntu Release Team |
| 2022-09-29 11:29:26 |
Graham Inggs |
summary |
Feature freeze exception: Socket activation |
[FFe] Socket activation |
|
| 2022-09-29 22:11:40 |
Graham Inggs |
speech-dispatcher (Ubuntu): status |
New |
Triaged |
|
| 2022-09-30 10:21:14 |
Sebastien Bacher |
speech-dispatcher (Ubuntu): importance |
Undecided |
High |
|
| 2022-09-30 10:21:14 |
Sebastien Bacher |
speech-dispatcher (Ubuntu): status |
Triaged |
Fix Committed |
|
| 2022-09-30 10:21:14 |
Sebastien Bacher |
speech-dispatcher (Ubuntu): assignee |
|
Nathan Teodosio (nteodosio) |
|
| 2022-10-26 06:10:07 |
Brian Murray |
speech-dispatcher (Ubuntu): status |
Fix Committed |
Triaged |
|
| 2022-10-26 06:10:40 |
Brian Murray |
removed subscriber Ubuntu Release Team |
|
|
|
| 2022-10-26 08:44:47 |
Ubuntu Foundations Team Bug Bot |
tags |
kinetic |
kinetic patch |
|
| 2022-10-26 08:44:59 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2023-01-25 20:33:37 |
Simon Quigley |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2023-01-25 20:33:39 |
Simon Quigley |
speech-dispatcher (Ubuntu): status |
Triaged |
Fix Released |
|
| 2023-05-12 11:57:55 |
Nathan Teodosio |
description |
[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.
[Rationale]
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.
And then,
> 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[2], but still not released.
I have built and installed the package in Kinetic and verified that spd-say still causes the dispatcher spawn and emits sound. Upstream test can also confirm this.
[1]: https://github.com/brailcom/speechd/issues/335
[2]: https://github.com/brailcom/speechd/pull/763 |
[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.
[Rationale]
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.
And then,
> 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[2], 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 'Reproduction case' for more details.
The installed socket needs to be started manually to function correctly, or else the system needs to be rebooted.
[Reproduction case]
Install the proposed speech-dispatcher from the PPA[3] and the snap[4] with spd-say. Then,
systemctl start --user speech-dispatcher.socket
snap run --shell geheim
$ XDG_RUNTIME_DIR=/run/user/1000 spd-say hi
[1] https://github.com/brailcom/speechd/issues/335
[2] https://github.com/brailcom/speechd/pull/763
[3] https://launchpad.net/~nteodosio/+archive/ubuntu/rebuilds/+build/26035882
[4] https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550 |
|
| 2023-05-12 11:57:59 |
Nathan Teodosio |
speech-dispatcher (Ubuntu): status |
Fix Released |
In Progress |
|
| 2023-05-12 11:58:23 |
Nathan Teodosio |
summary |
[FFe] Socket activation |
Service activation via Systemd socket |
|
| 2023-05-12 12:06:08 |
Nathan Teodosio |
attachment added |
|
speechd.debdiff https://bugs.launchpad.net/bugs/1991022/+attachment/5672708/+files/speechd.debdiff |
|
| 2023-05-12 12:14:38 |
Nathan Teodosio |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2023-05-15 11:45:49 |
Sebastien Bacher |
speech-dispatcher (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2023-05-15 11:45:50 |
Sebastien Bacher |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2023-05-17 15:37:29 |
Launchpad Janitor |
speech-dispatcher (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
bug task added |
|
speech-dispatcher (Ubuntu Jammy) |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
bug task added |
|
speech-dispatcher (Ubuntu Kinetic) |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
bug task added |
|
speech-dispatcher (Ubuntu Lunar) |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
nominated for series |
|
Ubuntu Focal |
|
| 2023-05-22 14:47:01 |
Nathan Teodosio |
bug task added |
|
speech-dispatcher (Ubuntu Focal) |
|
| 2023-05-22 14:47:08 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Focal): assignee |
|
Nathan Teodosio (nteodosio) |
|
| 2023-05-22 14:47:11 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Jammy): assignee |
|
Nathan Teodosio (nteodosio) |
|
| 2023-05-22 14:47:14 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Kinetic): assignee |
|
Nathan Teodosio (nteodosio) |
|
| 2023-05-22 14:47:17 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Lunar): assignee |
|
Nathan Teodosio (nteodosio) |
|
| 2023-05-22 14:47:20 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Focal): importance |
Undecided |
High |
|
| 2023-05-22 14:47:23 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Jammy): importance |
Undecided |
High |
|
| 2023-05-22 14:47:25 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Kinetic): importance |
Undecided |
High |
|
| 2023-05-22 14:47:30 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Lunar): importance |
Undecided |
High |
|
| 2023-05-22 15:09:18 |
Nathan Teodosio |
description |
[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.
[Rationale]
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.
And then,
> 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[2], 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 'Reproduction case' for more details.
The installed socket needs to be started manually to function correctly, or else the system needs to be rebooted.
[Reproduction case]
Install the proposed speech-dispatcher from the PPA[3] and the snap[4] with spd-say. Then,
systemctl start --user speech-dispatcher.socket
snap run --shell geheim
$ XDG_RUNTIME_DIR=/run/user/1000 spd-say hi
[1] https://github.com/brailcom/speechd/issues/335
[2] https://github.com/brailcom/speechd/pull/763
[3] https://launchpad.net/~nteodosio/+archive/ubuntu/rebuilds/+build/26035882
[4] https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550 |
[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[3] 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
[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 thesd_listen_fds(0) >= 1 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
[3] https://irclogs.ubuntu.com/2023/05/17/%23ubuntu-desktop.html
[4] https://github.com/canonical/firefox-snap/pull/12
[5] https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550 |
|
| 2023-05-22 15:15:44 |
Nathan Teodosio |
description |
[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[3] 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
[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 thesd_listen_fds(0) >= 1 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
[3] https://irclogs.ubuntu.com/2023/05/17/%23ubuntu-desktop.html
[4] https://github.com/canonical/firefox-snap/pull/12
[5] https://launchpad.net/~nteodosio/+snap/test-speechd/+build/2103550 |
[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
[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 |
|
| 2023-05-23 06:39:33 |
Nathan Teodosio |
attachment added |
|
speechd-lunar.debdiff https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1991022/+attachment/5674787/+files/speechd-lunar.debdiff |
|
| 2023-05-23 06:39:41 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Lunar): status |
New |
Confirmed |
|
| 2023-05-23 07:08:58 |
Nathan Teodosio |
attachment added |
|
speechd-kinetic.debdiff https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1991022/+attachment/5674789/+files/speechd-kinetic.debdiff |
|
| 2023-05-23 07:09:04 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Kinetic): status |
New |
Confirmed |
|
| 2023-05-23 07:41:03 |
Nathan Teodosio |
attachment added |
|
speechd-jammy.debdiff https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1991022/+attachment/5674811/+files/speechd-jammy.debdiff |
|
| 2023-05-23 07:41:11 |
Nathan Teodosio |
speech-dispatcher (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2023-05-23 07:57:01 |
Nathan Teodosio |
description |
[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
[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 |
[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 |
|
| 2023-05-23 07:57:06 |
Nathan Teodosio |
tags |
kinetic patch |
patch |
|
| 2023-05-23 07:57:14 |
Nathan Teodosio |
summary |
Service activation via Systemd socket |
[SRU] Service activation via Systemd socket |
|
| 2023-05-23 07:57:21 |
Nathan Teodosio |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2023-05-23 07:58:30 |
Nathan Teodosio |
bug task deleted |
speech-dispatcher (Ubuntu Focal) |
|
|
| 2023-06-05 14:52:38 |
Sebastien Bacher |
speech-dispatcher (Ubuntu Lunar): status |
Confirmed |
Fix Committed |
|
| 2023-06-05 14:52:42 |
Sebastien Bacher |
speech-dispatcher (Ubuntu Kinetic): status |
Confirmed |
Fix Committed |
|
| 2023-06-05 14:52:43 |
Sebastien Bacher |
speech-dispatcher (Ubuntu Jammy): status |
Confirmed |
Fix Committed |
|
| 2023-06-05 14:52:44 |
Sebastien Bacher |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2023-06-07 03:46:15 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Sebastien Bacher |
| 2023-06-09 19:30:30 |
Steve Langasek |
description |
[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 |
[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]
Its 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 |
|
| 2023-06-09 19:32:07 |
Steve Langasek |
speech-dispatcher (Ubuntu Lunar): status |
Fix Committed |
Incomplete |
|
| 2023-06-09 19:32:09 |
Steve Langasek |
speech-dispatcher (Ubuntu Kinetic): status |
Fix Committed |
Incomplete |
|
| 2023-06-09 19:32:10 |
Steve Langasek |
speech-dispatcher (Ubuntu Jammy): status |
Fix Committed |
Incomplete |
|
| 2023-06-12 06:09:09 |
Nathan Teodosio |
bug watch added |
|
https://source.puri.sm/kop316/mmsd/-/issues/3 |
|
| 2023-06-19 12:47:56 |
Nathan Teodosio |
description |
[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]
Its 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 |
[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]
Its 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 session must be restarted 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 #Or restart session or machine
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 |
|
| 2023-06-19 14:09:05 |
Sebastien Bacher |
speech-dispatcher (Ubuntu Jammy): status |
Incomplete |
New |
|
| 2023-06-19 14:09:07 |
Sebastien Bacher |
speech-dispatcher (Ubuntu Kinetic): status |
Incomplete |
New |
|
| 2023-06-19 14:09:10 |
Sebastien Bacher |
speech-dispatcher (Ubuntu Lunar): status |
Incomplete |
New |
|
| 2023-06-23 07:21:20 |
Sebastien Bacher |
description |
[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]
Its 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 session must be restarted 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 #Or restart session or machine
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 |
[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]
Its 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 session must be restarted or the system needs to be rebooted.
[Test case]
Install the proposed speech-dispatcher and the snap[5] containing spd-say. Restart the user session. Then,
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 |
|
| 2023-06-23 07:21:59 |
Sebastien Bacher |
description |
[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]
Its 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 session must be restarted or the system needs to be rebooted.
[Test case]
Install the proposed speech-dispatcher and the snap[5] containing spd-say. Restart the user session. Then,
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 |
[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]
Its 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 session must be restarted or the system needs to be rebooted.
[Test case]
Install the proposed speech-dispatcher and the snap[5] containing spd-say. Restart the user session so the new systemd unit gets activated. Then,
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 |
|
| 2023-06-23 21:41:22 |
Steve Langasek |
speech-dispatcher (Ubuntu Lunar): status |
New |
Fix Committed |
|
| 2023-06-23 21:41:23 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-06-23 21:41:28 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2023-06-23 21:41:31 |
Steve Langasek |
tags |
patch |
patch verification-needed verification-needed-lunar |
|
| 2023-06-23 21:48:29 |
Steve Langasek |
speech-dispatcher (Ubuntu Kinetic): status |
New |
Fix Committed |
|
| 2023-06-23 21:48:33 |
Steve Langasek |
tags |
patch verification-needed verification-needed-lunar |
patch verification-needed verification-needed-kinetic verification-needed-lunar |
|
| 2023-06-23 22:19:59 |
Steve Langasek |
speech-dispatcher (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2023-06-23 22:20:04 |
Steve Langasek |
tags |
patch verification-needed verification-needed-kinetic verification-needed-lunar |
patch verification-needed verification-needed-jammy verification-needed-kinetic verification-needed-lunar |
|
| 2023-06-27 13:04:58 |
Nathan Teodosio |
tags |
patch verification-needed verification-needed-jammy verification-needed-kinetic verification-needed-lunar |
patch verification-done-jammy verification-needed verification-needed-kinetic verification-needed-lunar |
|
| 2023-06-28 07:38:03 |
Nathan Teodosio |
tags |
patch verification-done-jammy verification-needed verification-needed-kinetic verification-needed-lunar |
patch verification-done verification-done-jammy verification-done-kinetic verification-done-lunar |
|
| 2023-07-10 10:48:26 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-07-10 10:48:24 |
Launchpad Janitor |
speech-dispatcher (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-07-10 11:05:09 |
Launchpad Janitor |
speech-dispatcher (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
| 2023-07-10 11:15:52 |
Launchpad Janitor |
speech-dispatcher (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-08-18 05:49:47 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
