We are having some kiosks that are used to command or order.
However, in noisy/outdoor environment, Google Cloud Speech sometimes produces wrong speech or commands.
What can we do to improve accuracy and remove/reduce the noise negative effect?
Thank you
I was able to find the following public reference here which explains that excessive background noise and echoes may reduce accuracy and to obtain optimal results from the Cloud Speech API, it is best position the microphone as close to the user as possible, particularly when background noise is present as the recognizer is designed to ignore background voices and noise without additional noise-canceling.
Related
I am creating an Amazon Alexa skill and would like to know the maximum duration of user input in seconds that a slot can hold. More specifically the AMAZON.SearchQuery type slot.
I'm not sure there is an official answer to this anywhere in public docs, but I don't think you'll be able to capture more than a few seconds (~8 max ?) of input. Plus if Alexa detects the user is done speaking, she will stop listening and process the utterance. Even a slight pause could be interpreted as the end of speech input.
I don't know your particular use case, but given all that, I would not recommend that slot type as a reliable way to capture long transcriptions. I don't believe there is a good way for skills to do at all currently.
This Amazon Lex blog is from 2017. I don't know if it will still work, but you can give it a shot.
Capturing Voice Input in a Browser and sending it to Amazon Lex
We want to use wpf application on tablet and looking for difference battery usage impacts between win app and wpf application?
Is there any comparision battery usage or document?
I doubt there is any type of documentation on what you want, but as suggested above, running your own tests shouldn't be too hard. I don't recall the APIs, but on any mobile device, there are going to be battery state objects you can access giving, at the very least, remaining battery energy. Write two test apps, each using the different paradigms. Run each, one at a time and for a long duration. Check on the energy usage at the beginning and end.
This is late for an answer but one aspect to remember about battery consumption is the use of the radios (Bluetooth and WiFi).
For tablet apps try to manage your app by stepping back and analyzing what data you'll need from the database and try to get the data in one shot so the OS can turn off the radio. If you make an sql call each time the user presses a button then the radio is on more and drains the battery. The OS might also leave the radio on "a little longer" in case you make another query.
For the rest of the UI of the app, you're safe to count on an 8 hr shift and then they dock it for recharge.
You can watch for the battery notifications as well so you can save the info in the app before the OS shuts you down.
Other than that, each app is unique and you'll need to run these tests during your QA cycle.
I am using google play game services – real time multiplayer API to add multiplayer feature to my mobile games. The engine I am using is Unity3D, but my question does not have to do with Unity (I believe so) so it is not important.
What I would like to know is the delay of the messages that are received over the internet to make my games smooth and synchronized.
I know that in other APIs like Photon you can easily find the delay of the message that is being received but I don’t seem to find it on google play game services API.
Is there any way to know the delay of the received messages on google play game services API?
Thank you for your time!
Determining the latency of the messages is a bit complex in the case of Google Real Time multiplayer APIs since the connections are peer to peer, so most of the data travels directly from one player to the other. (see for details: https://developers.google.com/games/services/common/concepts/realtimeMultiplayer#messaging)
The short answer is you can estimate it yourself, by adding sequence numbers to the messages, and then exchange the time difference each client experienced between the messages. I recommend measuring several messages, and sizes, and not have too much memory since conditions will change. Something like the average time between each message for 30-100 messages and then plan for the slowest link.
To make a good real-time game, you really should assume the latency is variable (sometimes it is low, others high), and it is always longer than you want :)
You might want to checkout https://gamedev.stackexchange.com/questions/58450/mobile-multiplayer-games-and-coping-with-high-latency which has a good discussion on how to handle this situation.
My problem is this...
I have two sites, one acting as an "Admin" site, the other as general "User" site. I need to broadcast live audio from the "Admin" site to all clients of the "User" site. I need to do this with <1 sec of latency.
Some restrictions include:
No install on "User" machines (the idea being the whole thing sits on the web)
If there needs to be a 3rd party plugin then Silverlight is preferred*
Any help much appreciated here
*I have tried IceCast with a flash client, IIS Smooth Streaming, Internet radio, all of which give us a latency of >5 secs.
Have you tried Flash with a server like Red5? You're generally going to get subsecond latency (though not much less than that), as it's designed for realtime communications. There's a learning curve with Flex and ActionScript, but if you're at all familiar with XAML, you can pick it up from the sample apps that come with Red5 pretty quickly.
Failing that, if there aren't too many clients, you can use one of the two real-time peer-to-peer solutions out there, namely Flash over RTMFP or WebRTC over JSEP/ICE/RTP. If you can ensure that all the clients are using Chrome, then WebRTC is probably your best bet. If you can ensure that they're not using Chrome, then Flash is a good choice. The current Flash Pepper client on Chrome is buggy up the wazoo when it comes to audio processing, and no sign of a fix in sight. (It doesn't support echo cancellation, and the volume of the audio goes up and down horribly.) So if you're using Flash, steer clear of recording and broadcasting your audio on Chrome. And I wouldn't recommend either approach if you have more than half a dozen clients - the number of audio streams is gonna overwhelm your "Admin" browser pretty quickly, I think. Better to push that out to something like a Red5 server.
Silverlight is a bad choice for more reasons than I can count. I'm saying this as a guy who spent several years trying to implement a realtime communication solution on Silverlight. Don't do it.
I want my Smooth Streaming video to play very well on low-end devices. However, the default settings seem very optimistic and continuously retry to play a too-high quality level, resulting in a very bad playback experience.
I know that the Silverlight Smooth Streaming media engine is fairly configurable. At the moment, I can only go at it with trial and error. Therefore, I figured I should ask for existing knowledge. Does anyone have any recommendations for me on this front - what sort of configuration to use?
My goal is to make the CPU heuristics very paranoid, so it will rarely try to upgrade the quality level. Even if it does, it should only upgrade by one step (however, I am not sure if there's any setting for that... it appears to upgrade in very large jumps right now - occasionally from 500 kbps straight to 3 mbps).
Take a look to http://forums.iis.net/t/1172146.aspx to get an idea of which settings can be tweaked.
Thanks,
Ez.
http://blogs.southworks.net/ejadib