I want to do Text-to-speech with many voices in many languages.
I tried SpeechSynthesizer (Ref: System.Speech) but it only allows 2 English voices. After installing 6 English voices from Microsoft site, I still cannot get any other voices.
I changed to SpVoice (Ref: Microsoft Speech Object Library). SpVoice can recognize 6 voices I just installed. The problem is when I call spVoice.Pause(), it always delay 0.5 second before it stops speaking completely. I also tried to set AlertBoundary for SpVoice but it didn't help.
SpeechSynthesizer can pause right away with SpeakAsyncCancelAll but only works with default voices.
Basically,the Pause method pauses the voice at the nearest alert boundary and closes the output device, allowing it to be used by other voices.
spVoice.Speak() method can be called synchronously or asynchronously. When called synchronously, the method does not return until the text has been spoken; when called asynchronously, it returns immediately, and the voice speaks as a background process.
I hope you are calling spVoice.Speak() synchronously. Thats why you are getting this issue. So use asynchronous method instead of synchronous,your problem should be solved. Then spVoice.Pause() will pause immediately.
SpVoice spVoice = new SpVoice ();
spVoice.Speak ("Testing spVoice",SpeechVoiceSpeakFlags.SVSFlagsAsync);
//......
spVoice.Pause();
Related
I created a main behavior for my NAOv6 (nao_main_behavior_V2) that is supposed to be executed on startup. It sets the robots language to german, activates some of NAOs LEDs and waits for me to touch his head sensors to activate a different behavior called Manual_Mode.
Every time I start NAO he executes the main behavior but stops as soon as I touch his head sensors to activate the other behavior. Using the Choreograph I can find this Error message:
[ERROR] behavior.box :onInput_onStart:16 _Behavior__nao_main_behavior_v28d046fMain2726901504:/Error! Manual_Mode_12: _Behavior__nao_main_behavior_v28d046fMain2726901504:/Manual Mode_29: ALBehaviorManager::runBehavior Box _Behavior__nao_main_behavior_v28d046fManualMode2716269632:/Speech Reco. Ger_1 has failed with error: Traceback (most recent call last): File "/opt/aldebaran/lib/python2.7/site-packages/albehavior.py", line 120, in _safeCallOfUserMethod func() File "", line 55, in onInput_onStart RuntimeError: ALSpeechRecognition::pushContexts AsrHybridNuance::xPushContexts You need to stop or pause the ASR engine to be able to make this call.
The Manual_Mode behavior accesses the speech recognition so I can say commands but I never access anything speech recognition related earlier.
Starting (or restarting) the behavior manually using Choreograph works just fine, everything works like it is supposed to and I don't get any Errors.
I tried using a third behavior during startup that starts the Main_Behavior but I get the same result.
The behavior was originally written for a NAOv5 and it worked without any problems.
I think this is related to some autonomous life running in the background (depending of the robot/version you use).
Try by stopping the autonomous life using api command when starting your "behavior_v2" or to change the nature of your "manual_mode" behavior (interactive/solitary) (or of the behavior).
About stopping the autonomous life: refer to api in ALAutonomousLife: setState or enableAnAbility methods (depending of your version).
About changing nature of behavior, it can be seen in this video for example: https://youtu.be/xPdNoiuaQag
I found a workaround. I created a launch trigger condition for my behavior:
(('Launchpad/LifeTime' ~30 ))
After NAO finishes its startup and 30 seconds have passed my behavior is being triggered and works without any problems.
With both DKPy-SITL and our APM2 board, the wait_ready method is causing our program to raise an API Exception due to the command list (waypoints) taking too long to download. In the past (with droneapi) this wasn't an issue for me. Some waypoints are being downloaded, but the process takes about 10 seconds for each one, which leads me to believe something weird is going on.
Are there any ways to speed up the download process? I've posted the relevant code below.
self.vehicle = connect(connection_string, baud=baud_rate,
status_printer=dronekit_printer, wait_ready=True)
and later in another asynchronous method
def commands(self):
commands = self.vehicle.commands
commands.download()
commands.wait_ready()
return commands
The error occurs on commands.wait_ready(). There has to be a faster way to download commands than sitting there for over 30 seconds on an i7 4790k processor, especially since I've run the same code off a slower computer in the past with droneapi. If need be, I can raise an issue on the dronekit github as well.
I had the same issue. First time download call always goes well (0 commands). Once you have uploaded some commands the second time you try to download it fails ('Timeout' exception).
What I did to solve this was calling clear without download after the first time.
Something like this:
cmds = vehicle.commands
if not cmds.count > 0:
# Download
cmds.download()
# Wait until download is finished
cmds.wait_ready()
cmds.clear()
# Add / Modify the commands here and then upload them
We have a C program (a client that connects to our server). The program uses Win32 API:s to create controls etc. It is a single-threaded application. Lately the application has started to hang at random in Windows 7.
Thanks to Application Verifier, I could detect problematic APIs and rectified them.
Now there are still some customers reporting a "non-responsive" situation.
A crash dump from their side reveals the following API:
SendMessage(HWND_BROADCAST, WM_DDE_INITIATE, (WPARAM)hClient, MAKELONG(aAppl,aTopic));
Yes its sending a DDE command to WinWord.exe. Task Manager shows Winword in non-responsive state.
Evtx reveals the following:
Fault bucket , type 0
Event Name: AppHangXProcB1
Response: Not available
Cab Id: 0
Problem signature:
P1: OurApplication.exe
P2: 14.14.1.50
P3: 537337f4
P4: b6f1
P5: 32
P6: WINWORD.EXE
P7: 15.0.4615.1000
P8:
P9:
P10:
Attached files:
C:\Users\diane-do\AppData\Local\Temp\WER91C7.tmp.appcompat.txt
C:\Users\diane-do\AppData\Local\Temp\WER958F.tmp.WERInternalMetadata.xml
C:\Users\diane-do\AppData\Local\Temp\WER968B.tmp.xml
C:\Users\diane-do\AppData\Local\Temp\WER969C.tmp.hdmp
C:\Users\diane-do\AppData\Local\Temp\WER9777.tmp.mdmp
These files may be available here:
C:\Users\diane-do\AppData\Local\Microsoft\Windows\WER\ReportQueue\AppHang_OurApplication.exe_e9b582fc22d416b8787c1184f6fe7fa19d63_cab_0fde97a1
Analysis symbol:
Rechecking for solution: 0
Report Id: 9e84daa9-eff8-11e3-a2fb-90b11c841d1a
Report Status: 36
Any help would be appreciated.
Please note the above is Win 7 64-bit, while our application is 32 bit. Don't know what build their Office 2013 is (32 or 64 bit)
I am aware of the following:
- DDE is old technology, but changing it is out of question now.
- For the above case, I cant use SendMessageTimeout APIs as our client has to wait until commands complete.
ONCE AGAIN, The hang (non-responsive state) happens at random, not always at DDE but various instances. While computing something, even while doing a simple operation as below. Customers launch our CHM file from our menu, then Alt+Tab to another application and then Alt+Tab back to our application, our application becomes non-responsive.
P.S: I also didn't find any document online as to how to interpret those evtx application logs , what P1 P2 stand for. What signatures meant or what fault bucket type are, or any meaning of AppHangXProcB1 or AppHangB1 etc. Please pass the link if you have for the same.
sendmessage is a blocking call it will return only after the receiver application processes the message. Here, it got blocked & it as well blocked your application from dispatching the message. Since your application can't process any further window messages, it hanged the GUI.
Check again all the processing done on processing a window message for any blocking calls like waitforsingleobject, recv, connect in it.
I've written a very simple front end for ffmpeg (converting stuff: video -> mp3) in GTK3.0/C for linux. For spawning ffmpeg I use g_spawn_async_with_pipes(). I thought this was the right way to execute stuff like that without having the GUI freeze up - but it does though. So - how can I prevent it from freezing - so I can f.e. display a spinner?
You might need to add something like"
while (gtk_events_pending ()) {
gtk_main_iteration_do (FALSE);
}
That is, to let GTK process the pending events (like drawing the UI).
I suppose you are processing the output of ffmpeg with g_io_add_watch
or similar.
I am trying a program in c that controls keyboard handler to blink NUMLOCK & CAPSLOCK LED's as a reaction of ctrl+alt+del push... please help me..
I kinda agree with KP. This is funny...
But if yer serious...
First:
There's a setleds program that might help you get started. It's been around for ages... Try man setleds.
Also, xset can be used (under X-windows) to change leds... (You may have to see which leds are enabled for changing in the X-config file.)
Second:
Detecting ctrl+alt+del is more of an issue as it's flagged specially by init. Look in /etc/inittab or /etc/init/control-alt-delete.conf or someplace like that, and you'll see lines like:
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -h now
Or:
# control-alt-delete - emergency keypress handling
#
# This task is run whenever the Control-Alt-Delete key combination is
# pressed. Usually used to shut down the machine.
start on control-alt-delete
exec /sbin/shutdown -r now "Control-Alt-Delete pressed"
So you'd have to disable that... Or simply have it run your keyboard-blink program rather than /sbin/shutdown.
Also, watch out for "Control-Alt-Backspace" -- Many X11 config setups enable this combination to shutdown the X server. (Option "DontZap".)
Third:
Now you need to find a way to pickup the control-alt-delete keypress. It's not impossible, but it may not be as simple as getc(). (The again, I could be wrong...)
Of course, if you don't want your program to have the keyboard focus. If you want this to happen while other programs are running in the foreground with keyboard focus... Well then yer looking at tweaking the kernel or some kernel driver. (Or having inittab run yer program instead of /sbin/shutdown.)
Any way you slice it, this is not a good Hello World type exercise.
Option:
Find the right place to trap Alt+Ctrl+Del and register a handler.
Use the KDGETLED/KDSETLED ioctl on /dev/console to changes the keyboard LEDs.
Good Luck!