tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] Speech synthesis use examples

[Florent T. <ft...@gm...>]

Sorry to continue spamming (just tell me if it's a nuisance), but it
allows me to keep track of the interesting info i find, and share it.

>From http://www.lirc.org/software.html

irmenu : IrMenu is a program that allows to navigate a text menu using
a remote control. Prompts are "displayed", that is, spoken, using your
favorite text-to-speech program, such as IBM ViaVoice or festival.

Which brings me to the question: can we use lirc with tux? My guess
is: not supported, yet, but coming...

Re: [tuxdroid-user] Speech synthesis use examples

[Florent T. <ft...@gm...>]

* From http://www.linux-speakup.org/projects.html

Speakup is a screen review package for the Linux operating system
(screen reader)

Trplayer is a Text-Mode RealMedia Player for Linux/Unix which has a
command-line interface. It can play RealAudio, RealVideo, MP3, and all
other media types supported by RealPlayer under Unix.

Speak Freely is a realtime text and audio IRC type program for the
Linux, Unix and Windows platforms.

TuxTalk is a software-based synthesizer for the GNU/Linux operating
system, originally based on rsynth.

* From http://www.netsaint.org/docs/hacks/festival.php

Audio Alerts of Problems  Using Speech Software

The Upsides

    * It gives immediate audio feedback on the status of your network,
which is quite useful if you're in the server room working on other
things
    * It will impress your boss and co-workers...

The Downsides

    * Its a bit of a waste of system resources, so its not really fit
for production machines
    * If you're in the server room alone on a weekend or at night,
having a machine start talking can scare the living daylights out of
you. It has happened to me before...

[tuxdroid-user] Speech synthesis use examples

[Florent T. <ft...@gm...>]

http://www.speechio.org/

    * speechd - Implements /dev/speech - was mentioned in the February
2001 issue of Linux Journal.
    * speech.irc v0.3 - Internet Relay Chat speech script for ircII,
BitchX, EPIC, etc.
    * slashes - slashdot news ticker that talks.
    * speech.pl - support for Xchat, a GNOME IRC client, by Joseph Elwell
    * licq-talk - support for Licq by Joseph Harth

    * NetSaint - "...have NetSaint talk to you and tell you whats
wrong with your network."
    * mouth.tcl - "A package for AOL's TiK that echos text to
/dev/speech" by Michael Matsumura.
    * speechbiff - speech enabled program resembling biff by Tony J. White
    * The /dev/speech concept was originally inspired by ircspeak by
Gareth Watts

Re: [tuxdroid-user] Dedicated sound normalizer / multiplexer daemon

[Florent T. <ft...@gm...>]

> > - handles multiplex / queuing of sound events (the wav merger doesn't
> > seem to me a long-term solution...)
>
> If you make reference to the python merge thing used by gtdi.py, it's not
> meant to play sounds but to store them in the internal flash.

Ok. My apologizes

> > - sound normalization to handle the mouth problem (open/close)

In fact, the speech recognition / sound daemon could do this: if "tux"
is said (indicating the beginning of a spoken "order"), the mouth
opens.

> We should try it with the speech recognition software, I'm not sure that will be a problem for it.

Hope so :)

> Now looking at tux again, I still can't find a good place for the
> microphone. Maybe close to the beak on the side. Time to release the first
> hardware hack ;-)

Well, my first idea would be to put the mic under/inside one wing. I
haven't opened tux yet, it there a wire between the mic and the MB?

> Yes, that was not meant to act as line-in and lin-out at all. Line-out is
> in fact just a headphone output. And line-in is even not connected to the
> computer, it's just a link to the amplifier so you can use tux as a small
> speaker box for your mp3 player. There's no frequency limitation on the
> line-in, it's just plain analog so you should get a better quality when
> using your portable player. The quality is limited by the speaker in this
> case.

Cool :) It's, indeed, a great idea i had'nt thought about: tux as a
"ipod dock" :), batterypowered speaker. And, it creates a
supplementary line out for such a device: listen with tux, record on
the line out. As it's a closed circuit, the sound quality will be
equivalent?

> Hope you get a better idea now.

Yup :)

Dunno if you did read it, but the article
http://www.linuxjournal.com/article/4723 shows a method where
/dev/speech incarnates the TTS daemon (just do echo "test" >
/dev/speech). I find it a quick and simple solution. Again,
Cvoicecontrol is what we want: not really speech recognition, but
voice-driven command launching. And it's perfect. Too bad it's
unmaintained...

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[David B. <da...@ja...>]

On Sat, 24 Mar 2007 16:40:36 +0100, Florent THIERY <ft...@gm...>  
wrote:

>> There's 5 values for the PWM of the wings and the spinning. I think the
>> api already uses this but by default it's at maximum speed. 0 is  
>> stopped,
>> 1 is slow and 5 is maximum speed.
>
> Good news !!!
>
>> Though there are much chances 1 and
>> maybe 2 are too small values so the current won't be able to even start
>> the motor.
>
> Well, just suppress the support of the useless ones in the api
>
>> I think the daemon should control this and only provide the
>> speeds that make sense in the functions.
>
> In fact, i was thinking of linear speed modulation, so that the
> movements are less rough.
>
> 1 - 2 - 3 - 4 - 5 - 5 - 5 - 5 - 4 - 3 - 2 - 1

Well, movements look rough because I wanted to stop the movement on the  
switch. When the eyes are closed, they need to be stopped very quickly  
otherwise they reopen. So I had to do braking by reverting the motor fo a  
short time. The mouth is less critical as going a bit too far doesn't open  
the mouth sompletely but if we want the switch to have a correct meaning,  
it should be pushed so we again need to stop very fast. For the wings,  
there's maybe a slight braking but I'm not sure, and there's nothing for  
spinning.

So it should be possible to start more smoothly but stopping smoothly will  
be much more complex. That's to be inplemented in firmware anyway.

Re: [tuxdroid-user] Dedicated sound normalizer / multiplexer daemon

[David B. <da...@ja...>]

On Sat, 24 Mar 2007 15:51:32 +0100, Florent THIERY <ft...@gm...>  
wrote:

> If we want "ultimate" modularity for soud (be it the choice of TTS
> engine, STT, or any sound-enabled sound), we may want to develop/find
> a dedicated sound daemon that:
>
> - creates a virtual sound device with an explicit naming convention (
> /dev/tuxmic & /dev/tuxspk for example)
> - downsamples/transcodes every incoming sound to 8bit 8khz sound (for
> instance, try to play an mp3 with xmms, it won't work :p)

using the alsa plughw devices uses dmix in the chain so resampling id done  
there. Try to play a file with
aplay -D plughw:1,0 wavfile

> - eventually filters the 500 Hz noise coming from the mic

That would be a good idea indeed

> - acts as a frontend for the TTS engines (if you input text to the
> daemon, it uses TTS; if it's sound, it sends it to tux)
> - handles multiplex / queuing of sound events (the wav merger doesn't
> seem to me a long-term solution...)

If you make reference to the python merge thing used by gtdi.py, it's not  
meant to play sounds but to store them in the internal flash. It computes  
indexes and merges all the sounds into 1 long wavfile which is played when  
tux is in storing mode. We don't want any blank space between the sounds  
in storing mode.

> - sound normalization to handle the mouth problem (open/close)
> - avoid/postpone tux animation when microphone usage is needed
>
> There's an inherent problem with the mic: it's in the mouth (it's one
> of the most discutable technical choices to me...), but WHY? Speech
> recognition programs rely heavily on a good sound level tuning, and
> the fact that the sound level varies from 50% when opening the mouth
> will not help...

I'm partly responsible for that, and indeed we should have found a better  
solution. We didn't want to have a hole in the front side of Tux and the  
microphone had to be on that side. At that time we didn't think about  
speech recognition, more about VOIP applications and the need to have to  
open the mouth to be able to use it was not considered a major problem.
  Now it's different if you have to let it the mouth open all the time. I  
now did some tests but didn't find such a big difference. The level is a  
slightly lower but the main difference I noticed is about the tone, when  
the mouth is closed, the higher frequencies are attenuated and the result  
is not as bright as it is when the mouth is open. We should try it with  
the speech recognition software, I'm not sure that will be a problem for  
it.

Now looking at tux again, I still can't find a good place for the  
microphone. Maybe close to the beak on the side. Time to release the first  
hardware hack ;-)

> Another technical choice that makes me wonder: there's a line in / out
> in the back of tux... But if i'm not mistaken, it will be limited to 8
> bits / 8khz. So these I/O won't really add feature, except for
> earphone operation...

Yes, that was not meant to act as line-in and lin-out at all. Line-out is  
in fact just a headphone output. And line-in is even not connected to the  
computer, it's just a link to the amplifier so you can use tux as a small  
speaker box for your mp3 player. There's no frequency limitation on the  
line-in, it's just plain analog so you should get a better quality when  
using your portable player. The quality is limited by the speaker in this  
case.

> Well, sorry to look mean, i'm just wondering why the engineering team
> did these choices...

Hope you get a better idea now.

Re: [tuxdroid-user] Dedicated sound normalizer / multiplexer daemon

[Florent T. <ft...@gm...>]

Cool. So a modification of esd would do the job

Re: [tuxdroid-user] Dedicated sound normalizer / multiplexer daemon

[Philippe T. <ph...@te...>]

Hi,
> - downsamples/transcodes every incoming sound to 8bit 8khz sound (for
> instance, try to play an mp3 with xmms, it won't work :p)
>
>   
Yes it can:
Select alsa output plugin -> configure -> type "plughw:1,0" manually
and select software volume control.

Or select OSS output plugin -> configure -> USB
but then no volume control is possible.

Or select esound output plugin
and launch esd with:
esd -d plughw:1,0

This last solution allows you to mix sources easily
e.g. when I was playing a mp3 with xmms I launched

mplayer -ao esd some_other.mp3 <http://www.paul.sladen.org/pronunciation/torvalds-says-linux.mp3>

So esound could be the kind of stuff you're looking for :-)
Phil

Re: [tuxdroid-user] New release

[David B. <da...@ja...>]

On Sat, 24 Mar 2007 16:24:17 +0100, Philippe Teuwen <ph...@te...>  
wrote:

>
>> Still, how does the "tuxdroid shell" function work? Doesn"t for me,
>> does it rely on an external dependency?
>>
> Yes,
> See http://www.tuxisalive.com/issue-trackers/apps/1
>
> Note that the tuxsetup features a tuxsh which is basically a script
> to call python -i /opt/tuxdroid/api/python/tux.py
>
> Phil

I had a try with tuxsetup yesterday and we now have symlinks in  
/usr/local/bin to /opt/tuxdroid/bin for tuxup, tuxdaemon, tuxttsdaemon,  
tuxgi and tuxsh.
tuxsh is just the call Philippe told, cat tuxsh:
#/bin/bash
python -i /opt/tuxdroid/api/python/tux.py

Add the symlink and this file and it should be fine. You can also use  
tuxsetup to create everything for you. It's just be created so it's the  
same as what's on svn now.

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[Florent T. <ft...@gm...>]

> There's 5 values for the PWM of the wings and the spinning. I think the
> api already uses this but by default it's at maximum speed. 0 is stopped,
> 1 is slow and 5 is maximum speed.

Good news !!!

> Though there are much chances 1 and
> maybe 2 are too small values so the current won't be able to even start
> the motor.

Well, just suppress the support of the useless ones in the api

>I think the daemon should control this and only provide the
> speeds that make sense in the functions.

In fact, i was thinking of linear speed modulation, so that the
movements are less rough.

1 - 2 - 3 - 4 - 5 - 5 - 5 - 5 - 4 - 3 - 2 - 1

Re: [tuxdroid-user] [Speech recognition] CVoiceControl evaluation report

[Florent T. <ft...@gm...>]

Here you can see screenshots of how it works. It's really perfect if
- we manage to make it work
- it works ok

http://www.linuxjournal.com/article/4723

[tuxdroid-user] [Speech recognition] CVoiceControl evaluation report

[Florent T. <ft...@gm...>]

Hi, i tried to test cvoice control

1- downloaded the deb, installed (ubuntu 6.10). When i try the
mandatory microphone calibration step (microphone_config), i get a
strange "xterm error"

http://www.kiecza.net/daniel/linux/cvoicecontrol/index-3.html

And that's it...

2- downloaded the sources, installed libncurses-dev. On my machine,
libpthread-dev install fails because of a conflict.

It's sad, because this software seems to handle the choice of the
devices to use.... >.<

Could please anybody try as well? So that i know if my machine is the problem...

Thx

Florent

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[David B. <da...@ja...>]

On Sat, 24 Mar 2007 14:54:24 +0100, Florent THIERY <ft...@gm...>  
wrote:

> YAQ (yet another question :p): is it possible to control the speed of
> the motors?

There's 5 values for the PWM of the wings and the spinning. I think the  
api already uses this but by default it's at maximum speed. 0 is stopped,  
1 is slow and 5 is maximum speed. Though there are much chances 1 and  
maybe 2 are too small values so the current won't be able to even start  
the motor. I think the daemon should control this and only provide the  
speeds that make sense in the functions.

Re: [tuxdroid-user] New release

[Philippe T. <ph...@te...>]

> Still, how does the "tuxdroid shell" function work? Doesn"t for me,
> does it rely on an external dependency?
>   
Yes,
See http://www.tuxisalive.com/issue-trackers/apps/1

Note that the tuxsetup features a tuxsh which is basically a script
to call python -i /opt/tuxdroid/api/python/tux.py

Phil

Re: [tuxdroid-user] New release

[Florent T. <ft...@gm...>]

Hi

Updated and tested the new version. Gtdi is much better, thank you !

Still, how does the "tuxdroid shell" function work? Doesn"t for me,
does it rely on an external dependency?

[tuxdroid-user] Dedicated sound normalizer / multiplexer daemon

[Florent T. <ft...@gm...>]

Hi

If we want "ultimate" modularity for soud (be it the choice of TTS
engine, STT, or any sound-enabled sound), we may want to develop/find
a dedicated sound daemon that:

- creates a virtual sound device with an explicit naming convention (
/dev/tuxmic & /dev/tuxspk for example)
- downsamples/transcodes every incoming sound to 8bit 8khz sound (for
instance, try to play an mp3 with xmms, it won't work :p)
- eventually filters the 500 Hz noise coming from the mic
- acts as a frontend for the TTS engines (if you input text to the
daemon, it uses TTS; if it's sound, it sends it to tux)
- handles multiplex / queuing of sound events (the wav merger doesn't
seem to me a long-term solution...)
- sound normalization to handle the mouth problem (open/close)
- avoid/postpone tux animation when microphone usage is needed

There's an inherent problem with the mic: it's in the mouth (it's one
of the most discutable technical choices to me...), but WHY? Speech
recognition programs rely heavily on a good sound level tuning, and
the fact that the sound level varies from 50% when opening the mouth
will not help...

Another technical choice that makes me wonder: there's a line in / out
in the back of tux... But if i'm not mistaken, it will be limited to 8
bits / 8khz. So these I/O won't really add feature, except for
earphone operation...

Well, sorry to look mean, i'm just wondering why the engineering team
did these choices...

What do you think?

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[Florent T. <ft...@gm...>]

Btw thanks for creating the wiki articles :) I'll add the things i
find with time...

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[Florent T. <ft...@gm...>]

> This makes me talk about nex functions I want to develop in the daemon.
> For now, the firmware only does something like:
> - start_spinning(pwm)
> - spin_right(angle, pwm)
> - spin_left(angle, pwm)
> - stop_spinning()
>
> I don't think these functions should be accessible from the api, at least
> not in the standard set of functions. I would want the daemon to add a
> level on top of that which provides some more complex functions that can
> also benefit from the status received and stored. For example, the
> functions that should be accessible from the API could provide spinning
> functionalities like:
> - spin for a specific angle
> - spin for x turns
> - spin for a given time
> - sets in absolute angle (where 0 could be used to reset in initial
> position, the obsolute position should be stored in the daemon and updated
>  from the status and commands sent)
> - stop spinning

Ok

YAQ (yet another question :p): is it possible to control the speed of
the motors?

Re: [tuxdroid-user] Release of tuxttsdaemon please!

[David B. <da...@ja...>]

On Fri, 23 Mar 2007 22:25:52 +0100, Philippe Teuwen <ph...@te...>  
wrote:

> Hi,
>
> Current gtdi is incompatible with tuxttsdaemon v0.2.8
> Please release the new one :-)

Indeed, it's been released in the tuxsetup package but they forgot to  
update it on the separate package of the download page. Will ask to fix  
that Monday.

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[David B. <da...@ja...>]

On Fri, 23 Mar 2007 16:13:58 +0100, Florent THIERY <ft...@gm...>  
wrote:

>> It should be fine to do some resmaple if necessary
>
> 16 to 8 Khz downsampling + signal filtering
>
> For instance, audacity filtering does it just fine: you select a
> portion of the recording that has only the noise in it, and it
> automatically removes it, really a great feature. We may be able to
> use the libs/plugins...
>
> Any ideas:
> - how to downsample in real time
> - how to filter the 500 Hz noise

It's indeed upsampling from 8kHz to 16kHz. Audacity do it fine and there's  
probably a lot of small command line tools that can be used to do the same.

I'm not sure we'll need to remove the 500Hz noise, it's not that important  
and the voice recognition software may be not sensitive to it.
But if you want to record something with your Tux, filtering the 500Hz  
noise in Audacity afterwards improves the quality.

> For now, animation is restricted to 1/4 turn actions. When the
> firmware will be more sphisticated, will we have more fine control
> over movements? How precise are the step-by-step motors? Will we have
> the possibility to do smaller/slower movements? This would reduce the
> noise.

Probably not from the firmware. We don't use step-by-step motors but  
standrad ones, The motor is stopped whenever a tooth pushes on a position  
switch and we can only detect 4th of turns that way. It's possible though  
to use the motors in another way from the software side by running the  
motor only for a specific time period instead of running it for a specific  
angle. Start-wait-stop motor with a smaller PWM should give you finer  
movements, but the position will never be very accurate I'm afraid.

This makes me talk about nex functions I want to develop in the daemon.  
For now, the firmware only does something like:
- start_spinning(pwm)
- spin_right(angle, pwm)
- spin_left(angle, pwm)
- stop_spinning()

I don't think these functions should be accessible from the api, at least  
not in the standard set of functions. I would want the daemon to add a  
level on top of that which provides some more complex functions that can  
also benefit from the status received and stored. For example, the  
functions that should be accessible from the API could provide spinning  
functionalities like:
- spin for a specific angle
- spin for x turns
- spin for a given time
- sets in absolute angle (where 0 could be used to reset in initial  
position, the obsolute position should be stored in the daemon and updated  
 from the status and commands sent)
- stop spinning

[tuxdroid-user] Release of tuxttsdaemon please!

[Philippe T. <ph...@te...>]

Hi,

Current gtdi is incompatible with tuxttsdaemon v0.2.8
Please release the new one :-)

Phil

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[Philippe T. <ph...@te...>]

> http://www2.tux-is-alive.com/wiki/Test-to-speech
>
>   
Stupid typo when I created the page, I moved it to
http://www2.tux-is-alive.com/wiki/Text-to-speech

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[Philippe T. <ph...@te...>]

Florent THIERY wrote:
>> It should be fine to do some resmaple if necessary
>>     
> 16 to 8 Khz downsampling + signal filtering
>
>   
Here it's about upsampling from 8 to 16 as the microphone is 8 and the 
soft requires its input at 16.

I created a page with all your good searches so we can track those 
alternatives:

http://www2.tux-is-alive.com/wiki/Test-to-speech


Phil

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[Florent T. <ft...@gm...>]

> It should be fine to do some resmaple if necessary

16 to 8 Khz downsampling + signal filtering

For instance, audacity filtering does it just fine: you select a
portion of the recording that has only the noise in it, and it
automatically removes it, really a great feature. We may be able to
use the libs/plugins...

Any ideas:
- how to downsample in real time
- how to filter the 500 Hz noise

> There's 2 problems: 1. when the motors are running or the speaker is used, the microphone will get that noise with a high level

Well, personnally i'm not gonna use tux's motors that much: only when
it requires much attention for instance, so i guess it won't be a big
trouble for me. Really, regarding the animation capabilities, what can
we imagine that would exploit them?

I was also wondering:

For now, animation is restricted to 1/4 turn actions. When the
firmware will be more sphisticated, will we have more fine control
over movements? How precise are the step-by-step motors? Will we have
the possibility to do smaller/slower movements? This would reduce the
noise.

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

[David B. <da...@ja...>]

On Fri, 23 Mar 2007 14:08:30 +0100, Florent THIERY <ft...@gm...>  
wrote:

> But it's 16 kHz, 16 bit, mono, not 8 kHz...
>
It should be fine to do some resmaple if necessary. I really think the  
quality of the microphone is not that bad. There's 2 problems: 1. when the  
motors are running or the speaker is used, the microphone will get that  
noise with a high level and 2. there's some 500Hz noise due to the RF  
digital modulation.

We have to do some tests, once you selected something that's good for you,  
I'll give it a shot with tux and also with an external microphone.

Thanks for your information,
david