speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speechd-discuss Digest, Vol 58, Issue 5


From: DD
Subject: Re: Speechd-discuss Digest, Vol 58, Issue 5
Date: Wed, 21 Aug 2024 16:08:09 -0400
User-agent: mu4e 1.9.18; emacs 29.2


One, of many, things I've left out is to acknlwledge a middle round, ala
festival:  There's a service that doesn't speak  directly to SD, but
loads the model(s) and is long runbning, so does not incur
initialization overhead per TTS request.  I /know/ festivqal does this
since it won't work without something external to SD infrastructure
starting a 'festival --server' process[1].

Besides piper, I'm interested in coqui and have been doing with coqui
what's been done for piper, which is fun and a nice start.  Probably
others have done this too.

The real thing I'm working on is coqui ala festival.  Assuming piper
support would also benefit from this approch (ie it's not already
running a non-init-overhead process), so I would also do piper, of course.

What I'm really wondering about is, given a non-init-overhead per
request solution, does the native C matter?  I suspect not, but we'll see!

I would like to do a native module anyway though[2],, so thanks for the
encouragment and I'll keep the list posted.

Derek


[1]  Actually, for me, if the festival service is not up and responsive
SD will try to init sd_festival output module.  OM init will fail b/c
festival service is not up and functional, so festival output module
initialization fails and, again at least for  me, I need to reboot, with
festival service up, or I will never see festival in spd-say -O outpout
no matter how many procs I kill or systemctl (with or without sudo) I
perform.  Very frustrating.  There is doc on starting festival at boot
time on ubuntu in:
/usr/share/doc/festival/README.Debian.gz .

[2]  This means it could be written in, eg, rust or zig or nim,,
depending on build infrastructure.  Or, more seriously, C++, ala kali.

speechd-discuss-request@nongnu.org writes:

> Send Speechd-discuss mailing list submissions to
>       speechd-discuss@nongnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.nongnu.org/mailman/listinfo/speechd-discuss
> or, via email, send a message with subject or body 'help' to
>       speechd-discuss-request@nongnu.org
>
> You can reach the person managing the list at
>       speechd-discuss-owner@nongnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Speechd-discuss digest..."
>
>
> Today's Topics:
>
>    1. Re: Speechd-discuss Digest, Vol 58, Issue 3 (Kyle)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 20 Aug 2024 20:50:12 -0400
> From: Kyle <kyle@gmx.it>
> To: speechd-discuss@nongnu.org
> Subject: Re: Speechd-discuss Digest, Vol 58, Issue 3
> Message-ID: <9d92379c-69ce-4755-a69a-ac85cf00df7f@gmx.it>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> I certainly wouldn't stop anyone from writing a native module for Piper.
> I have it running via Pied here, which is installed via Flatpak and can
> set up speech-dispatcher's user configuration to run the selected Piper
> voice. But getting Piper installed and using a native module would
> probably be somewhat more responsive than the generic configuration,
> which is piping everything through sox, paplay or aplay, depending what
> is installed on the system. So definitely continue working on the native
> module, and hopefully we will have a distro packaged Piper at some point
> in the not too distant future.
>
> ~Kyle
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Speechd-discuss mailing list
> Speechd-discuss@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/speechd-discuss
>
>
> ------------------------------
>
> End of Speechd-discuss Digest, Vol 58, Issue 5
> **********************************************




reply via email to

[Prev in Thread] Current Thread [Next in Thread]