I am trying to recognize numbers in the app. when I am speaking numbers it calls onEndOfSpeech() method but I still have to speak the number. Sometimes it works fine and sometimes even if there is delay of 0.5 sec causes End of speech.
End of speech is expected to be raised after 0.5 seconds of silence. It is important to provide fast response in interactive applications. If you do not want to process it, you can ignore it and continue recognition.
Related
I am making a video game, which is a pretty small 2D shooter. Recently I noticed that the frame rate drops dramatically when there are about 9 bullets in the scene or more. My laptop can handle advanced 3D games and my game is very very simple so hardware should not be a problem.
So now I have a very big code (at least for one person) and I am pretty confused where I should look for? there are too many functions and classes related to bullets, and for example, I don't know how to analyze if the rendering function has problems or the update function? I could use MVS 2015 debugging tools for other programs, but for a game, it is not practical, for example, if I put a breakpoint before the render function, It should be checked 60 times in a second plus I can't input anything so I will never have bullets to test render function! I tried to use task manager, and I realized that CPU usage goes up really fast for each bullet, but when the game slows down only 10 percent of the CPU is used!
So my questions are:
How can I analyze functions when I can't use debugging tool?
And why game slows down while it still can use system resources?
To see what part consumes most of the processing power, you should use a function profiler. It doesn't "debug", but it creates a report when it's finished.
Valgrind is a good tool for that.
Why the game slows down? Depends on your implementation. I can create a program that divides two numbers and make it take 5 minutes to calculate the result.
We're in the video-game industry as well and we use a very simple tool on PC for CPU profiling: very sleepy.
http://www.codersnotes.com/sleepy/
It is simple, but really helped me out a lot of times. Just fire up the program from IDE and let very sleepy run for a few thousand samples and off you go!
When it comes to memory holes, Valgrind is a good tool, as already noted by The Quantum Physicist.
For timing, I would write my own small tracing/profiling tool (if my IDE does not already have one). Use a text debugging output to write short messages to a log file. Something like that:
void HandleBullet() {
printf("HandleBullet START: %i", GetSysTime());
// do your function stuff
printf("HandleBullet END: %i", GetSysTime()); // or calculate time of function directly
}
Write those debugging messages in all of the functions where you think they could take too long.
After some execution time, you can look into that file and see if something obvious happened (blocking somewhere).
If not, use a high level language of your choice to write a small parser for your created log file to tidy up and analyze your output. Calculate stuff like overall time spent in some function, or chart which functions took the longest. Should not be too difficult, if you stick to a log message style which is easy parsable for you.
I have the project to develop an application that would allow a computer to 'send' a window to another computer.
In order to do that, I need, of course, to capture the concerned window's output from my program.
Google searches leaded me to no relevant result, neither with libX11 nor libxcb.
I also tried to record screenshots with xwd and import, but as they are quite slow, I'm getting up to 3.5 fps
Any help on how I could do that will be welcome (either using libX11, libxcb, or something else)
By the way, I attempt to use c++ for this program
Thanks for reading,
Edit:
The fps test was made without sending files. It was just like "I took screenshots for 5 minutes, and I got 900 pictures"
I think you will need to record screenshots and compress them before sending over network to make things faster. Also, you would need to decrease the quality of the screenshots (user configurable) to make it faster.
Plus there are different techniques to send only the changes (diff of screenshots) to the other computer.
Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.
When things are this slow, it's ok to profile by watching stdout :) This:
std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";
...
BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
std::cout << "B";
return DIENUM_CONTINUE;
}
Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.
This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:
http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup
There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.
Any ideas about why it could be so slow will be greatly appreciated!
EDIT:
I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.
But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.
I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!
Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.
I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.
Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.
I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.
Changing the Audio output from the DAC to anything else also weirdly solved the issue.
This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.
I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!
I had the same issue. I have a Corsair K65 LUX RGB keyboard. I updated CUE and it seems to have fixed the issue
Got same issue when having my Corsair K55 Keyboard. Changing the keyboard of USB port fixes the issue for a while, but then it comes back later on. So it seems to be a buggy drivers issue.
As DaFox has pointed out, a likely cause appears to be certain device drivers being enabled. I contacted JDS Labs support (who sell one device which happens to install one such driver) and they kindly pointed out that the root cause is actually a bug within Windows (not the installed driver), and they actually provide the solution on their troubleshooting page. See Games hang or experience loading delays, which explicitly mentions VID_262. Disabling this driver fixes the issue without apparent side effects (under the condition that that is the only driver triggering the bug). As for what exactly is going wrong within Windows, here there be dragons.
So I guess the go-to solution (for users) is to scrape all the troubleshooting and FAQ pages for all devices which you have ever connected to your system and see if there is a mention of delays/lag caused by a driver.
As a software developer, you will probably want to benchmark the execution time of the affected code and kindly tell the user there is something wrong with their system configuration and where to look for how to fix it in case it is unreasonably long.
Same issue with Corsair K70 Keyboard.
Quickly reconnecting keyboard fixes this, until next time. Usually happens after some DirectInput devices removed from the system or go to sleep.
This has been plaguing me as a developer and my friend as a user for years. All games using DInput, SDL SDL_INIT_JOYSTICK or anything depending on that, took extremely long to initialize.
It was caused by a faulty driver of a DAC, and as pointed out by DaFox, disabling the corresponding USB Input Device resolved the issue. Although it's labeled with a different manufacturer name, the vendor IDs match.
The hardware ID of the device is USB\VID_262A&PID_9023&REV_0001&MI_00.
Same issue appears to happen with a Steelseries Apex 7 keyboard. Unplugging and plugging that keyboard back again got rid of 3 freezes (of 10 seconds each) while enumerating USB devices.
I'm doing a little beginner c++ program based on the game of snap.
When i output the card objects to the console, because of the computers processing speed naturally, a whole list of the cards that were dealt just appears. I thought it might be nice if i could put a pause between each card deal so that a human could actually observe each card being dealt. Since i'm always working on both Linux and Windows and already had < ctime > included i came up with this little solution:
for(;;){
if( (difftime(time(0),lastDealTime)) > 0.5f){ //half second passed
cout << currentCard <<endl;
lastDealTime = time(0);
break;
}
}
At first i thought it had worked but then when i tried to speed up the dealing process later i realised that changing the control value of 0.5 (i was aiming for a card deal every half a second) didn't seem to have any effect.. i tried changing it to deal every 0.05 seconds and it made no difference, cards still seemed to be output every second i would guess.
Any observations as to why this wouldn't be working? Thanks!
The resolution of time() is one second -- i.e., the return value is an integral number of seconds. You'll never see a difference less than a second.
usleep() is in the standard C library -- it has a resolution in microseconds, so use that instead.
time() and difftime() have a resolution of a second, to there's no
way to use them to manage intervals of less than a second; even for
intervals of a second, they're not usable, since the jitter may be up to
a second as well.
In this case, the solution is to define some sort of timer class, with a
system independent interface in the header file, but system dependent
source files; depending on the system, you compile one source file or
the other. Both Windows and Linux do have ways of managing time with
higher resolution.
If you want to make sure that the cards deal at precisely the interval you request, then you should probably create a timer class too. We use:
In Windows use QueryPerformanceFrequency to get the system tick time and QueryPerformanceCounter to get the ticks
On Mac Carbon use DurationToAbsolute to get system tick time and UpTime to get the ticks.
On Linux use clock_gettime.
For sleep use:
One Windows use Sleep();
On Mac Carbon use MPDelayUntil();
On Linux use nanosleep();
the big issue with your code from the way I see it is not the fact that you have not found a single-platform version of sleep but the fact that sleep is actually meant to stop the CPU from processing for a period of time, but yours will not stop processing and your application will use up lots of resources.
Of course if your computer is dedicated to just running one application it might not matter, but nowadays we expect our computers to be doing more than just one thing.
Does the N900 allow me to display additional information in parallel to the native application or does the latter always have priority over my process?
I'm interested in displaying additional information based on caller id.
If it's possible, can you name any pitfalls or give small python code examples / or tipps to get started?
detecting incoming call might be the smallest problem you will see in this journey - you can start with this thread
now consider few other factors before you decided whether you want to continue or not:
calls come not only as phone call but also as SIP call, Skype call, GTalk call, etc
call signaling is relatively resource-heavy due to time constraints vs blocked by I/O, etc
call dialog should work ok in portrait and landscape, so you might need to go down extending call architecture not writing my own little thing in 1-2 weekends
internal eMMC storage is not quick and gets slow on 2+ threads trying to write
if you are Ok with risk to spent time and bump into limitations of Maemo5 platform put on end-of-lifecycle hook -- consider learning down googleing keywords maemo5 telepathy mission-control . this is starting point not definitive guide -- you have to learn quit many different things before you start to approach plugging call progress dialogs.