Comment by moron4hire | Hacker News Reader

Comment by moron4hire | Hacker News Reader

What I think a lot of people don't realize is just how easy speech recognition is these days. By that I mean, to create an application that has as good of voice recognition capability as, say, Google Now, is not that much harder than setting up any other event-driven input system. I'm sure the actual recognition of speech is quite difficult. But there are a fair number of APIs available that make it easy to use in your applications.

Almost every programming language has a canonical API that is extremely simple to set up. In .NET and Google Chrome, it's even first-party, and I only mention those because they happen to be the ones I've used.

And text-to-speech is no different. You can get to "good enough" so easily that I'm somewhat perplexed why more people don't do it.

I just think there is a perception that adding a speech recognition feature to your app is "hard". It's difficult to design a good speech-based user experience (I've found longer phrases work better than single-words, and it's good to try to match on homophones as well), but actually integrating the code is not that tough.

So I would encourage you to ignore Amazon. Seriously, you could make this in a weekend in a Google Chrome browser on an Android device that you plug a nice microphone into.

In google chrome it reaches out to google to do the recognition.

.NET seems to be built on the technology that has shipped with Windows for a while, and yet Cortana etc still reach out to the mothership for their speech recognition, so there are probably significant benefits to doing so, otherwise someone would have made theirs work offline and touted it.

I'm guessing that matching a pre-specified pattern with some amount of error is easier than transcribing arbitrary voice, which you need for search.

But I definitely agree, I regularly wish I could stop google maps' directions with a voice command when I get to a part of a route that I already know well enough to complete myself.

With the cloud-based systems, it seems they made them from the perspective of their mobile devices, then ported the APIs to the desktop experience. The idea they are trying to put across is that it costs less energy on the phone to fire up the radio and send it to The Cloud--waiting a whole second just for network and processing queue latency--than it is to process locally. I don't think that is actually the case and it's just a sell to get all data to go through their systems.

There aren't more popular client-side APIs because there aren't more popular client-only applications, and there aren't more popular client-only applications because developing the user experience is hard. I think, if you used one of these systems to figure out a good UX, then it would give you the impetus to chase down a good client-side solution for speech recognition.

It is not just a sell. I build Neural Networks as part of some work I am doing, and the kinds of multi-layer deep networks that do the recognition just don't perform well on small devices. Also the best systems often have many different trained networks and specialized routing to find the best network for your accent, cadence, noise level, etc. Having all of these weights on your local device, running all the tests, running through any of the required preprocessing, and asking the network what the answer is, converting the results, etc. is going to be too much for your phone or low powered device. While there might be other reasons for them to send data to the cloud, to get the accuracy you really need beefy servers (potentially with GPU's or something more exotic like FPGA's), and potentially multiple servers working in concert.

Since I don't know the factors involved and you do, I must then ask how to reconcile this with the fact that the first version of Dragon NaturallySpeaking was released in 1997. My smartphone is definitely more powerful than even a top-of-the-line 1997 desktop PC.

Now, I am sure Dragon V1 would be quite underwhelming to my modern notions of how computers should work. But I would even say my smartphone is better than a middle-of-the-road PC from 2010. It's better than my PS2, and even my PS2 had a few games that had speech interface (some Navy Seals game, it worked pretty well).

What factors are at play? Is it the noise cancellation? Seems like a stationary device in a home has the ideal chance to create a reusable noise cancellation profile.

I was thinking about making my own as well! I haven't done any research but you'd need a smartphone dock, a good microphone/speaker (wireless microphones/speakers around the house?!?). Better yet, mount a tablet on the wall somewhere convenient/attractive (living room, next to thermostat, etc.) and wire everything behind it.

Change Android settings to always listen when screen is on, then keep screen always on (dims when not active). Voice-controlled App support galore! Google Now! Develop whatever you need/want!

The Echo is a neat idea put into action, but it can be hacked together in a much better way, very easily.

I've thought about doing it, but I don't already have the devices in my home that are capable of being automated and I've got enough money dumped into projects that required bits like this that I never finished as it is.

I would, however, be interested in trying to create a room simulator. I did work on living space automation for a while, a few years ago (specifically for hotels, not homes). One of the most difficult parts of designing good user experiences was the lack of ability to rapidly test, due to the need to setup a ton of devices, associate them together, maybe even flash them with new ROMs. You could get in two, maybe three tests as day, if you were really cooking. I wanted to be able to test as fast as I could compile code, you know, like I had gotten used to in every other software project I had ever worked on. But electrical engineers work with primitive tools and seem to like it.

This just came up in the Github Explore Today newsletter: https://github.com/jhauswald/sirius

It's not as hard as it was, yes, but only if you accept to depend on closed APIs. On .NET, I guess you're depending on WSR?

It's a sight better than signing a whole NDA. And it's no different a situation than all the other APIs we have to deal with in Android or iOS. You gotta fight the right battles at the right time.

But yes, I believe the System.Speech.Recognition namespace wraps WSR. But given that it's in the System namespace, it should be a part of the ECMA standard for .NET. Aaaaaand, yep, it appears it is available in Mono, so I assume they are managing the cross-platform dependency issues for you.

Could also check out api.ai they do a pretty good job of voice recognition into machine commands.

Interesting, thanks.

Reply on news.ycombinator.com