Firefox snap & speech-dispatcher

Hello there!

I’ve tried a few Text-To-Speech demos to find out speech-dispatcher is not supported in the snapped Firefox.
Are there plans regarding speech-dispatcher in Firefox?
This sounds like an opportunity to discuss further handling of TTS as I’m starting to think a dedicated interface for speech-dispatcher may sound reasonable.


@willcooke - fyi, here is another one for the firefox snap maintainer.

Has there been some activity around speech-dispatcher in Firefox?
Since the snap is the prefered package shown in GNOME Software I have concerns around missing a11y support.

Sorry for the lack of reply so far @beidl, this thread somehow went under my radar.
I’m not familiar with what’s required for text-to-speech to work, but I can confirm that this doesn’t work in the firefox snap (nor in the chromium snap). I tested with, and the combo box that should contain a list of languages is empty, so I’m guessing confinement prevents the application from querying the system for available languages. I couldn’t observe any relevant denials though.

The snaps would need to include libspeechd2 in their stage packages, and we would indeed need a dedicated interface as speech-dispatcher appears to use a unix socket ($XDG_RUNTIME_DIR/speech-dispatcher/speechd.sock) for communication.

I have quickly rebuilt the chromium snap with those two changes but that doesn’t appear to be enough, this will require further investigation. I’m putting the task in my backlog.

Thanks for the input, @oSoMoN, pretty much what I assumed.
I’ve tried to come up with a patch for snapd itself to add the required interface, a draft-ish gist is available here:

A sample application snap is available here, only using the speech-dispatcher plug:

It’s not much and doesn’t seem to be enough for full support as spd-say within the example snap tries to connect to the socket at $XDG_RUNTIME_DIR/snap.$SNAP/speech-dispatcher/speechd.sock instead of $XDG_RUNTIME_DIR/speech-dispatcher/speechd.sock,
which would’ve been fine if the snap.$SNAP subdirectory existed with a symlink pointing to the actual speechd socket (which seems to be the default behaviour with wayland plug-consuming snaps).

Manually creating directory + speechd.sock symlink results in a connection failure when starting spd-say (probably due to AppArmor denial or missing directory in the snaps namespace).

1 Like

What does that denial look like?

Here’s the output with the mentioned speech-dispatcher example snap:

$ speech-dispatcher-example-snap.spd-say "some text"
Failed to connect to Speech Dispatcher:
Error: Can't connect to unix socket /run/user/1000/snap.speech-dispatcher-example-snap/speech-dispatcher/speechd.sock: No such file or directory. Autospawn: Autospawn failed. Spawn error 8: Failed to execute child process "/usr/bin/speech-dispatcher" (No such file or directory)

This is due to /run/user/1000/snap.speech-dispatcher-example-snap itself missing, the socket would probably map over fine.

It appears application snaps could ship their own speech-dispatcher daemon with the app but this would result in concurring TTS operations unable to properly demux the output.

Update: I have filed an upstream bug to track and hopefully resolve the issue.