[VINUX-DEVELOPMENT] Next speech project?

[William Hubbs]

Hi all,

On Fri, Nov 05, 2010 at 04:02:53PM -0400, Bill Cox wrote:
> Hi, Tony.  Comments below.
> 
> On Fri, Nov 5, 2010 at 3:26 PM, Tony Sales
> <vinux.development at googlemail.com> wrote:
> > Hi Bill, I suppose 'OpenTTS' would be the sensible ?(but boring)
> > choice, but I think 'geekspeak' (in tribute to waywardgeek) sounds
> > much more fun and could be used for speech recognition as well (or
> > 'geektalk for the speech recognition.' )

Tony, for your information, OpenTTS is dead upstream.  The whole reason
for us forking from Speech Dispatcher is gone now, and we are all
working on speech dispatcher.

> 
> I like geekspeak and geektalk.  I figure a guy who can convince people
> to use his custom Linux OS knows more about good marketing than I do!
> Thus, my choice of sonic over pbr.
> 
> > In terms of 'sonic' I realise this can be used to create faster
> > e-books etc, but could this approach be used to improve the speed of
> > Orca in realtime, or is it limited to creating faster recordings?
> 
> The sonic library is designed for streaming audio, so it fits
> naturally into applications that process speech, like
> speech-dispatcher, espeak, and the emacspeak speech server.  On the
> other hand, Orca does not actually ever have access to the generated
> speech, so it can't go there.  But, if Orca uses speech-dispatcher,
> there's no reason it wont work.

My opinion about this is it should go further down the chain than
Speech-Dispatcher.  It should be built into the synthesizers, like
espeak, and maybe there should be an api call added to espeak to make it
work.  Then, sd could access it that way, and so could the emacs speech
servers.

> I think it's simply the nature of innovation that you have to do
> everything yourself.  No one else is committed to your ideas like you
> are.  So, I think I'll have to integrate sonic into speech-dispatcher
> myself.  I mean no complaint to the speech-dispatcher guys... this is
> just human nature, especially when you're not paying anyone to do
> anything.  If it's ok with you, I'll test it in Vinux/Maverick and see
> if I can get it accepted upstream.  I'm thinking of adding the
> following options in speechd.conf to control sonic's behavior:
> 
> SonicMin, and SonicMax: When set, these parameters would define what
> is meant by "0" speed in Orca, and "100" speed.  In this case, we
> would intercept the speed setting commands from Orca and adjust the
> sonic speed multiplier, rather than forwarding any speed change
> command to the TTS synth.  So, for example, I like to listen between
> 1X and 4X speed, so I could set these to 1.0 and 4.0, and adjust the
> actual speed in Orca settings to any speed in this range.  If not set,
> then the behavior would revert to how it works now, where the TTS
> synth is responsible for the speed.
> 
> SonicDefaultSpeed: If sonic is enabled, it is sometimes desirable to
> use a particular speech synthesis speed in the TTS synth, even though
> we're speeding it up or slowing it down as a post process to
> synthesis.  For example, espeak slowly removes pauses between words
> and phrases as you increase speed to -s 450.  So, speeding up espeak
> output that was generated with -s 200 sounds different, and perhaps
> better, than speeding up the espeak default speed output.  This option
> would allow users to set the default speed for the TTS synth.
 
 This would not go in the main config, but I think in the configs for
 the speech synthesizers that use it, Then our modules could use the api
 calls from the synthesizers, say espeak for example.

What do you think?

William

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20101105/4adb611e/attachment.pgp>