Re: Using festival in Orca
Hello,
Carles Pina i Estany, le sam. 10 janv. 2026 08:06:11 +0100, a ecrit:
> On 03 Jan 2026 at 19:06:01, Samuel Thibault wrote:
> > Hello,
> >
> > Carles Pina i Estany, le ven. 02 janv. 2026 08:00:10 +0100, a ecrit:
> > > > > I plan to document the steps in, at least:
> > > >
> > > > We'd rather integrate it into the package, so people don't have anything
> > > > to do but install the speech-dispatcher-festival package.
> > >
> > > I've tried to write the systemd units for socket activation for the Wiki
> > > documentation and that would be re-usable to add them in the
> > > speech-dispatcher-festival and I found some "blockers" (blockers for me,
> > > might be possible though and happy to try again).
> > >
> > > I haven't written socket activation services before but I found out:
> > > I think that the application (festival in that case) should be able to
> > > reuse an already opened socket? (systemctl binds 1314 and passes the
> > > file descriptor to it?).
> >
> > Ah, right, festival would need to be taught how to get that fd, like
> > speech-dispatcher was taught.
>
> I did it in:
> https://salsa.debian.org/carlespina/festival/-/merge_requests/1
Nice!
It'll be useful to also submit upstream.
They would most likely want to make the support optional on the presence
of systemd.
Also, better add -lsystemd to LIBS rather than on the link line. That'll
be needed for making the support optional anyway.
> > > Then I thought that systemd could bind 1314 port, proxy to a second port
> > > (1315). And systemd could spawn "festival --server" indicating 1315.
> >
> > That would be a headache, better just teach festival to use
> > SD_LISTEN_FDS_START:
> >
> > if (sd_listen_fds(0) >= 1) {
> > /* Daemon launched via Systemd socket activation */
> > server_socket = SD_LISTEN_FDS_START;
> > }
>
> This is what I did.
It went well indeed and seems to be working fine!
> > > This almost worked and I could make it work... but I thought that would
> > > not be usable for speech-dispatcher-festival package because we want
> > > each "festival --server" running using the active user, so in a
> > > multi-user system that would cause problems. Is it correct that we want
> > > each user to have their own "festival --server" or one as
> > > "festival-server" user would be enough for the system?
> >
> > Mmm, it's true that with multi-user questions rise. But if a user
> > starts festival --server without socket activation the problem is
> > already there, so I wouldn't bother trying to fix it. Actually, with
>
> I implemented the socket activation. But I am still not sure of the user
> details and if it's getting into a place that should not be...
>
> What I did is socket activtation, and Festival runs as festival user
> using DynamicUser=yes (my understanding is that it's a new user every
> time).
That can be nice indeed.
> > some containerization magic that could exist some day, user sessions
> > could have their own 1314 port so users don't step on each other. Anyway
> > that's for somebody to solve.
>
> What would you change or double check on the Draft MR?
Sorry, I missed one word in my sentence: "Anyway that's for somebody
else to solve."
I.e. I don't think we absolutely need to care for now and can just leave
it to further work.
> > > For the Wiki documentation: since a user choose to enable the festival
> > > --server because the user is happy with it: I thought that keeping it
> > > simple is better than using socket activation. But I could change it.
> >
> > Again, the end goal is to just integrate it in the festival package, so
> > that users won't *even* have to set up a systemd unit, but just install
> > speech-dispatcher-festival and voila.
>
> I think that the MR would do that.
It seems so, yes, thanks!
> On the other hand: would it confuse or cause any problem (e.g. security
> problem) in a multi-user machine to have a festival server running under
> a common users for all the users in the machine? Do you foresee
> something or is good enough?
If festival has some vulnerability, it can lead to information leakage,
indeed. But again, that's already the case currently, so we are not
making the problem worse. Actually this is making it a bit better by
running festival as anonymous user.
I have integrated your changes into the debian package git repository
for now, so it'll be included in next upload.
A next step would be to make festival dynamically notice the addition of
new voices. For instance, installing festvox-italp16k after festival got
launched, spd-say -o festival -L doesn't show it.
Samuel
Reply to: