Voice Application Development for Android

You know, it's wild how second nature it's become to just talk to our devices. Hey, Google, set a timer, Siri, what's the weather? We barely think about it.

Yeah, it really feels like something we just take for granted now, But.

Pull back for a second. How does that actually happen? How does your phone hear you, understand what you want, and then you know, do something.

It does feel a bit like a magic trick, doesn't it. But behind that simple interaction is this whole layered world of technology.

It's quite complex, actually, and that's exactly the world we're diving into today. We're taking a deep dive into how you build these voice based applications, specifically thinking about Android devices.

Okay, and our guide for this exploration is fascinating. It is a detailed technical guide published back in twenty thirteen.

Twenty thirteen, so a bit of a snapshot from that era exactly.

It gives us a really interesting look at the tools and approaches developers we're using them, leveraging Google's own capabilities and also some open source software.

Right, So, our mission in this deep dive is to kind of cut through the complexity. We want to unpack the core concepts the essential building blocks.

Fundamental, Yeah, the.

Fundamentals, and show you the journey developers took to create apps you could talk to all without you needing to pour over the original technical manual yourself.

Sounds good.

We'll start with the absolute basics, speaking and listening and build up from there, maybe getting into complex conversations and even early virtual assistance.

Okay, let's unpack this starting at the very beginning, seems right. Before a device can respond or have any kind of conversation, it first has to be able to speak. And here right.

The fundamental capabilities Android provides for this are text to speech TTS and automated speech recognition or ASR.

And thinking about why these are important, Well, it opens up so many possibilities. Imagine your hands are full like you're driving and need directions.

Oh yeah, it's simple then or and.

This is crucial for accessibility. Think about someone with a visual impairment using a green reader that's TTS or ASR helping someone communicate if they have difficulty speaking, much like Stephen Hawking used speech synthesis technology.

They're really foundational tools. Okay, let's start with TTS text to speech. Simply put, it turns written text into spoken audio.

Right, and the technology works in stages. First, it needs to understand the text itself, things like you know how to pronounce words that look similar but sound different based on context.

Like reads versus read just exactly.

Or converting numbers and abbreviations into full words. The cool part for developers often is the system handles a lot of this linguistic complexity. You don't always have to get into the weeds.

Okay, So it understands the text, then it has to generate the actual sound exactly.

A common approach, especially around the time this book was written, was something called concatenative synthesis.

Concatenative synthesis okay, okay.

Think of it like building a sentence by stitching together tiny prerecorded pieces of speech. These could be sounds, syllables, words, even short phrases.

Ah like digital lego bricks for voice.

Kind of algorithms select the right pieces and join them smoothly, trying to mimic natural rhythm and intonation. When it's done well, it can sound remarkably natural.

It's kind of amazing how they make those pieces fit together. But wait, if they're stitching together pre recorded bits, why not just record a human voice actor saying everything the app might need to say.

That's a great point, and sometimes apps do use professional voice actors, you know, for specific tromps where quality and consistency are paramount.

Like a standard greeting or instruction exactly.

But TTS becomes absolutely essential when the text is dynamic, when you can't possibly pre record everything it might need to say.

Ah, right, like reading out a text message.

You just got, or a news headline that just updated, or.

Someone's name from your contact.

List Precisely, you just can't anticipate every single phraser name. So while the quality might sometimes be a trade off compared to say, a perfectly recorded voice, linets offers that vital flexibility for dynamic content.

And Android has had this built in for ages. Right, how do developers actually hook into it?

Yeah, the capability has been there since Android one point six. Believe or not, developers use the framework provided. A key step is making sure the necessary language data is actually on the user's.

Device the voice itself.

Yeah, the voice files the rules for that language. The system lets developers check for this using something called an intent, and even prompt the user to install it if it's missing.

Okay.

The book suggests using a common software design pattern, a singleton, basically ensuring only one instance of the TTS engine is created. This helps manage resources efficiently smart and the examples in the book show how you might use this to say, read back text the user piped in, or maybe read text loaded from a file. You can specify the language too, like English or even regional variation.

Okay, so that's how the device speaks. Now the other side hearing us automated Speech recognition ASR. This is turning our spoken words into text.

Right, and like TTS, it involves steps. First, the device needs to capture the sound from the microphone and process it. Think of it as cleaning up.

The audio, getting rid of background noise.

Yeah, removing noise maybe echo, and just preparing it digitally for analysis.

Then comes the recognition part itself. Yeah, breaking down the audio into.

What sounds basically yeah, into tiny segments phones the basic sounds of the language, and then it tries to match them.

Wow.

This is where powerful statistical models come into play. These models are trained on massive amounts of recorded speech, learning how different sounds are typically pronounced in different context by different people.

Wow.

Okay, they build what's called an acoustic model. It's essentially a statistical map of how sounds relate to words.

But words can sound exactly alike you mentioned read and read or two and two. How does it know the difference?

Ah, good question. That's where another statistical model helps, the language model.

Language model.

This one understands the probability of words appearing together in sequence. It knows that after I went, the word two is far far more likely than two.

Right context exactly.

The language model provides that crucial context to help resolve those ambiguities.

And the result isn't always just one single interpretation, is it like? It's not always certain?

No, definitely not. Typically, the ASR system gives you back a list of possible results, ranked by how confident it is in each one. A list, yeah, it's often called an end best list. Each possibility comes with a confidence score, usually from zero to one. A score near one means the system is pretty.

Sure it got it right, and that's useful for the developer.

Incredibly valuable. They can just pick the top result. If the confidence is high, or if it's lower, or if the top one doesn't make sense in context, they can look at the others in the list. Or maybe even use the confidence score to decide HM I better ask the user to confirm this.

This capability has also been around on end for a while since version two point one. Often when you tap the little microphone icon on the keyboard.

Yes exactly, and developers have flexibility here too. You can use a simple built in tool and intent that handles the speak now, prompt and feedback automatically, super easy, quick and dirty, pretty much. Or if you want more control over the look and feel the user interface, you could use a more advanced component a speech recognizer instance. This lets you manage the UI yourself and react to specific recognition events like when the user starts or stops speaking.

More control, more work typically yeah.

The book again suggests using a library approach here, like an ASRLB, just to keep the code organized and reusable.

And you mentioned language models. Can you tell the system what kind of speech to expect, like am I dictating an email or just barking a search query?

Exactly? You can specify different language models. There's one design for free form dictation like long sentences, and another optimized for shorter phrases like web search queries.

Ah.

The book does note though, that even with these models, the input can still be quite open ended, so the developer might need to do more processing afterwards to figure out the specific command or meaning.

Oh and because these systems often connect to cloud services for the heavy lifting.

Right, the recognition part. Yeah, the app usually needs permission to access the Internet, and you need to handle potential errors like no speech detected or no match found or maybe a network problem.

Got it. So we've got the building blocks. The device can speak TTS, and it can listen and turn speech into text ASR even giving us a list of possibilities with confidence scores. How do we actually put those together to build simple interactions?

That's the next logical step, right, moving from just hearing or speaking to creating a basic back and forth. Think about those early voice actions.

Like on Google Now back in the.

Day, exactly telling your phone call mom or go to Wikipedia dot org. These are structured commands, simple cause and.

Effect, and they're built just by combining those core TTS and ASR capabilities we just talked about.

Pretty much the book provides them straightforward examples. One is an app called voice Search.

It just takes whatever you say, listens using ASR right.

Grabs the top result from that end best list the one with the highest confidence it seems it's right, and immediately plugs it into a standard Android web search intent. Boom search results appear very.

Simple, okay, but that immediately brings up a potential problem which you hinted at. What if the ASR got it wrong exactly? This seems particularly tricky in another example app. The book mentions voice Launch, which tries to launch an installed application based on what the user says. Right, what if you don't say the exact app name, like maybe you say music player, but the app is actually called play Music.

This is where the idea of similarity measures comes in. It's a crucial concept. The app needs a way to compare what the user said to the actual names of the apps installed on the device to find the best to match, even if it's not identical.

How does it do that? Just check if the letters are similar.

That's part of an orthographic similarity looking at the spelling. But crucially, it can also look at phonetic similarity.

How words sound alike?

Yes, so it could figure out that, I don't know, photos and photos probably refer to the same thing, even if the spelling's different.

Okay, that's clever.

The book mentions using algorithms like soundex for this phonetic comparison, although it notes the specific implementation they included was primarily tuned for English. The key thing is normalizing the input first, like her moving spaces, making everything lower case before you do. The comparison makes sense.

Okay, So even with similarity measures, ASR isn't perfect. That potential for error means you often need to double check with the user right confirm things absolutely.

Confirmation is vital for robust interaction. The book includes a simple example building on that Voicer chap. After recognizing something like pizza places right, yeah, might use TTS to ask did you say pizza places? And then it uses ASR again, but this time listening specifically for a simple.

Yes or no uh, constraining the expected input exactly.

It's a basic but really important step, especially when you're dealing with single critical pieces of data before taking an action.

So we can make the device speak, listen, perform. These simple command action pairs handle some ambiguity with similarity, and even ask for basic yes no confirmation. But these interactions still feel quite rigid. You know, you have to say things in a very specific way or is just one command at a time. How do you make the conversation more flexible, like guide the user through collecting multiple pieces of information?

Okay, yeah, that takes us into the realm of more structured conversations, often called form filling.

Dialogue form filling like on a website.

Exactly the same idea. The goal is to gather several distinct pieces of information from the user, one by one, but doing it through voice instead of textboxes and dropdowns.

Okay, So, like booking a flow, it might ask what city are you flying from? Then once you answer, what is your destination exactly?

And then maybe what date do you want to travel. To manage this, you need a system. You need a way to define the pieces of information you need. Think of these as slots to be.

Filled like fields on a form.

Precisely, and you need an algorithm, some logic that knows how to navigate the conversation to collect the info for EID slot in some sensible order.

The book points to something called VoiceXML as a kind of model for this.

Yeah. VoiceXML is or was, a W three C standard for defining these kinds of voice dialogues often used in call center systems. It uses concepts like forms, which contain fields or slots. Each field has a prompt, which is what the system asks the user.

What is your destination right?

And optionally, fields can have grammars associated with them, which constrain or help interpret what the user can say in response.

So for a destination field, the grammar might only accept city names.

Potentially yes and VoiceXML uses a concept called the form interpretation algorithm or FIA. It's basically the logic engine that steps through the form, asking for one piece of required information at a time until all the necessary slots are filled. The book uses a simplified subset of these ideas specifically for Android development, and.

There's a specific library in the book to help build this.

Yes a library called form filip containing classes to represent these forms and fields. It works by parsing XML files that the developer writes. These XML files define the structure of the conversation, what questions to ask, in what order, which fields are needed, so.

The conversation logic is separate from the main app code exactly.

It uses standard Android tools like XML pull parser handled via another helper library, xml lib to read these definitions. Then a key piece called the dialogue interpreter class steps through this structure, triggering the right TTS prompt and listening for ASR responses to fill each field.

Does it handle background tasks like parsing might take time?

Good point. It's designed to do the potentially slow work like parsing the XML or waiting for ASR in the background using Android's acing task, so the main app remains responsive. That separation of concerns is really nice.

A great example used in the book is the music Brain app. What does that do?

Right? The music Brain demo app uses this form filling library. It guides the user through a voice dialogue asking for details like maybe a word that appears in an album title or a start an end.

Date range, using that form structure.

Exactly once, it collects all the pieces of information needs by filling the slots in its form, and use that collected information to query the music Brain's web service, which is a big online music database.

Ah. So it's combining the voice interface with external data a.

Mashup, precisely. It shows how you can take destruction data gathered via voice and uses to interact with online services retrieve information. Process it may be filter or sort the results like sorting albums by release date using helper classes, and then present that back to the user, perhaps speaking the results or showing them on screen.

Okay, so form filling lets us manage these multi step conversations to get structured data like album name and date range. But you mentioned that the ASR input within each step was still somewhat open ended in these basic examples. How do we make the app understand more than just the words the user says? How do we get it to understand the meaning behind the words?

Right? That's a critical step towards more intelligent interaction, and that's where grammars come in, leading us into the field of natural language understanding or NLU.

Grammars and NLU Okay.

Grammars are tools designed specifically to help the application interpret more complex user inputs. They help extract not just the sequence of words, but the underlying meaning and specific structured pieces of information.

So going beyond just recognizing show me flights to London as a sequence of words.

So understanding that the user's intent is to see flights and the destination parameter is London.

Got it? How do you create these grammars?

The book discusses two main approaches. First, there are handcrafted.

Grammars written manually by developers.

Exactly, you write them yourself, often in an XML format like SRGS Speech Recognition Grammar Specification, though the book uses its own simplified XML format. You define the structure of acceptable phrases using rules, items within rules, alternatives, optional parts, and links between different rules.

Can you give an example for that flight query?

Sure, you might have a top level rule like rule ID fine flight. Inside that you might have an item for the phrase show flights or fine flights. Then maybe an optional item repeat zero one for the word two, and then crucially a reference to another rule like ruler ref u r F hashtag city which defines all the valid city names.

And the hashtag city rule would list London, Paris, New York right.

And within those rules you can use special semantic tags. So next to the item London in the city rule, you might have a tag like tag out lhr tag. This tells the system if the user says London, don't just return the word London, return the airport code lhr AH.

Extracting structured data directly based on the grammar match. That's powerful, very powerful.

But as you can imagine writing these grammars to cover all the different ways a user might phrase.

Something flights to London, show me London flights. I want to flight to London exactly.

Designing handcrafted grammars for spontaneous, unpredictable speech is incredibly hard and very time consuming. That's the big challenge.

So what's the alternative.

That's where the second type comes in. Statistical grammars, or more broadly, statistical NLU.

Models learn from data.

Yes, these aren't written by hand. They're trained on vast amounts of real world language data using machine learning techniques, and.

The advantage is they can be much more flexible handle variations you didn't explicitly code for.

That's the key benefit. Because they work based on probabilities and patterns learn from how people actually speak, they can often handle more or irregular wording, synonyms, even slightly ungrammatical inputs that would break a strict handcrafted grammar.

What's the downside?

The main one is they require huge data sets to train effectively, and access to these trained models often comes via cloud services. The book mentions a service from a company called Maluba as an example of a real world statistical NLU system available around that time.

And that kind of system tries to identify the core intention and the relevant details the entities.

Precisely, you give it a phrase like what's the weather in Belfast for tomorrow, and a statistical NLU system could analyze it and return something structured like categories whether action is, check status, and the entities are location, billfast, and date tomorrow, maybe even resolving tomorrow to the actual calendar date. It's focused on extracting that core meaning, often regardless of the exact sentence structure used.

Does the book include a library to help developers work with these different grammar types.

It does. An NLU lib. It contains classes for handelling those handcrafted grammars, parsing the XML definitions into Java objects, inverting the rules into patterns, often using regular expressions behind the scenes, and then using Java's matching tools to check user input against these patterns. It also extracts the semantic information based on those tags we talked.

About, and for the statistical ones.

The library also incling code demonstrating how to connect to external statistical NLU services like that mlluda API, sending the user's text and parsing the structured semantic result that comes back, assuming, of course, the developer has API access.

And is there a demo app to play with this?

Yes, a grammar test app. It's quite useful. It lets you input text, either typing it or using the results from ASR, and then test that input against either a handcrafted grammar file you provide or by sending it off to the statistical.

Service so you can see the difference exactly.

It shows you whether the input is considered valid according to the grammar and more importantly, what semantic information or structured representation some extracts. It's a clear way to see the different capabilities and outputs of the two approaches to understanding language.

Okay, this is really building up. We've gone from basic speaking and listening to simple commands, structured form filling, and now understanding meaning with grammars and NLU. How do we make these voice apps even more robust and user friendly, maybe for a wider audience or in different situations.

Well, two key aspects the book covers next are multi linguality and multimodality.

Multi linguality supporting different languages seems obvious, but important.

Absolutely essential if you want your app to reach a global audience. It means being able to use TTS and ASR and languages other than.

Just the default How do developers handle that.

They specify the languages using standard codes like ISO six three nine tosh one codes N for English as for Spanish and so on. The Android system provides ways again using intents to check which languages are actually supported or installed on the user's specific device.

Because not all devices might have all languages pre installed, right, and.

This ties directly into the broader concept of localization in Android development, you know, providing different text strings, images layouts, and resource folders like resvalues for Spanish users versus Ree's values and for English users. It's about adapting the whole app experience. The book has a very simple silly parrot app just to show switching TTSASR language.

Okay, so that's multiple languages. What about multimodality sounds complex?

It just means combining voice interaction with the traditional graphical user interface, the GUI, the buttons and screens we're used to tapping.

On ah, voice and touch working together. Why do that?

Because sometimes tapping is just easier or faster than speaking for certain inputs, or users might want visual feedback confirming what the system understood, or maybe they start by voice and when finished by touch or vice versa. The idea is to create a seamless link, a link between what between the fields of information we were talking about in form filling dialogues and the visual elements on the screen

Okay, so how does that work in practice?

Imagine you have a field in your voice dialogue for say, urgency, with options low, medium, high. You might also have radio buttons on the screen for the same options. Right, If the user says medium urgency, the app not only fills that voice field internally, but it also automatically checks the meeting radio button on.

The screen ah synchronization exactly.

And conversely, if the user taps the high radio button on the screen, the app knows that the urgency information has been provided, so the voice dialogue system shouldn't ask for it orally anymore. The state is shared.

That sounds really useful, but potentially complex to manage.

It requires careful design. Grammars become important here too, to ensure that the voice input for a specific field actually matches one of the valid options available in the corresponding GUI element, Like the items.

And a drop down list, and the book provides hell for this too.

Another library, Yes, building on the form filling one, a multimodal form FILLIP. It extends the basic form library by adding grammar checking within the dialogue flow, so it only accepts voice input that actually matches the grammar defined for the current field. And crucially, it includes methods like oral to gee and GI toral specifically designed to synchronize the state between the internal voice feels and the visual GUI elements.

Is there an example app for this?

They use a mock send message app as a demonstration. It lets the user provide details for sending a message recipient urgency, maybe the message body itself, either by speaking the.

Information following the form filling prompts.

Right, or by interacting directly with the GeOI elements on the screen, like picking a contact from a list or tapping a radio button for urgency. The app keeps track of the information consistently, regardless of whether it came via voice or touch. It really highlights how voice and touch don't have to be separate, isolated interaction modes. They can compliment each other within the same task.

Okay, this is quite a journey We've layered on all these capabilities speaking, listening, simple commands, handling, ambiguity, multistep forms, really understanding language with Grammars in NLU, adding flexibility with multiple languages, and combining voice with the screen through multimodality. What happens when you take all these pieces and integrate them into one coherent system, Well, that's when.

You get into the realm of virtual Personal assistance.

Vpas AH the serious, the Google Assistance, the Alexis of the world exactly.

These are the conversational agents we're much more familiar with today. They really represent the culmination of all these underlying technologies we've been discussing, designed to understand potentially complex requests and perform a whole range of tasks.

And the fundamental challenge for a VPA trying to bring everything together must be accurately figuring out the user's intention from whatever they happen to say, however they say it.

That's the core of it. And as we saw when discussing Grammars in NLU, you can approach this understanding in different ways. You might try to classify the user's input using statistical methods trained on lots of.

Data, which is good for more open ended questions or requests.

Right, or you might use more structured grammars for specific commands, extracting the core intent in any relevant details or parameters. Often modern systems use a hybrid approach.

And once the intention is hopefully understood, the VPA needs more logic. Right, it needs a system to decide what to do next.

Definitely, it needs dialogue management. Based on the understood intent and the current state of the conversation, the dialogue manager decides the next action. Does it need to ask a clarifying question, Does it have enough information to perform the task? Does it need to access some data?

And then it needs to generate a response.

Yes, response generation figuring out what to say back to the user via PTS or what information to display on the screen, or what action to actually perform on the device or via web service.

This whole idea of conversational AI has a long history, doesn't it even before smartphone?

Oh yeah, it goes way back. The book even mentions early chatbots like Eliza from the nineteen sixties, but for building more sophisticated vpas around the time the book was written. It focuses on using a specific platform called Pandora Bots.

Pandora Bots, what's that?

It's a platform still reunt today actually for creating and hosting conversational agents or chatbots uses a language called AML. AML Artificial Intelligence Markup language is based on XML, and it lets you define the bot's conversational behavior using categories. Each category has a pattern which is basically.

What the user might say a potential input phrase.

Right, and a template which defines how the bots should respond. You can use wild cards like in the patterns to make them more flexible, matching multiple variations of user input, and there are special tags like srey that let you redirect from one pattern to another, helping to handle synonyms or rephrase requests without duplicating logic.

What happens if the user says something that doesn't match any pattern?

Good question? AML has the concept of an ultimate default category, a fallback pattern that matches anything else, usually triggering a response like sorry, I didn't understand that or could you rephrase? It's crucial for making the bot seem less brittle.

Okay, So the core conversation logic matching input patterns to output templates runs on the Pandora Bots platform. How does that connect to doing things on the Android device.

This is where a really interesting feature mentioned in the book comes in, specifically designed for mobile vpas. It's the UB tag oh ob out a band. It's a special tag that the AML developer can embed within the box response template alongside the text the bot is supposed to say,

So the conversation, logic and knowledge stays centralized on the Pandora bot server define an AML, but the actual device actions searching, launching apps, making calls, opening URLs are triggered locally on the Android device by these hidden commands embedded in the bot's response exactly.

It's a clever way to decouple the conversational intelligence from the specific device functionalities. The book provides a vp lib library to handle this communication, connecting to a specific Pandora bot online using its bodhead sending the ASR input, parsing the XML response from Pandora bots, looking for the spoken part often marked by a FAT tag, and checking for ubtags, and then running the course wonding functions on the device

Does the book include sample vpas built using this Pandora bots approach?

It does. It described three Jack, Derek and Stacy. Jack is based on a well known general purpose amail bot called Alice, designed for broad open ended conversation. Derek, on the other hand, is presented as a specialized bot. It trains specifically on a particular knowledge domain. The example uses FAQs about type two diabetes. This highlights how you can encode expert or domain specific knowledge using these AMMEL patterns and templates.

So one generalist, one specialist, and Stacy.

Stacy is basically Jack the general conversational bot, but enhanced with that oub tag functionality, so Stacey can not only chat, but can also actually control device functions like searching online or launching apps based on understanding those embedded commands within the conversation flow.

That really brings it all together. If you look back at how the book illustrates the overall VPA structure, you know, starting with ASR capturing the audio, then spoken language understanding whether that's NLU, grammars or AML pattern matching to figure.

Out the intent right the understanding part.

Then dialogue management deciding the next step, response generation formulating the output, and finally TTS speaking the response.

All while potentially connecting to external data sources, knowledge bases, and triggering those device actions via things like the ouptech.

You can really see how all those individual building blocks we discuss, TTS, ASR, forms, grammars, multimodality fit together into that complete VPA system.

It is the full picture. Now show how you assemble these components to create those conversational agency.

And that really brings our deep dove to a close, doesn't it. We've journeyed all the way from the absolute fundamentals, the device's ability to speak using TTS and listen using ASR.

The core building blocks, through.

Building those first simple command interactions, bringing in ideas like similarity measures and confirmation.

Making them a bit more robust, and.

Structuring more complex multi turn conversations using form filling dialogues, managing the flow to gather.

Information, getting that structured data, then.

Diving into how to understand user input more deeply, moving beyond words to meaning using both handcrafted and statistical grammars via.

NLU, extracting intent and entities, and.

Then adding layers of flexibility through multilinguality supporting different languages and multimodality, seamlessly combining voice with graphical interfaces.

Making the interaction richer and more adaptable.

And finally we saw how all these technologies converge in the architecture of virtual personal assistance, using platforms like Pandora bots with AML and leveraging clever techniques like that OOB tag to bridge the gap between conversation and actually doing things on the device.

Absolutely, This deep dive, even though it's rooted in a technical guide from over a decade ago, now really gives you a solid conceptual shortcut. It helps you understand the core challenges and the fundamental building blogs involved in bringing voice interaction to life on a device.

Yeah, it lays out the pieces really clearly and considering all these elements together, from breaking down sounds and words to understanding complex intent, managing dialogue flow over multiple turns, generating responses, and having the ability to trigger pretty much any device function or connect to any web service. It really opens up your imagination, doesn't it, to the kind of truly personalized voice applications you could potentially create.

Right, It makes you think beyond the general purpose assistance we mostly use today. What if a voice assistant wasn't just generic? What if it was deeply, deeply specialized.

Yeah, Like, imagine a VPA that understands the incredibly specific vocabulary, the jargon, the unique needs of your particular hobby or your specific job, maybe using a custom built grammar or a finely tuned n LU model, and it could instantly connect you to niche online resources or internal databases that a general assistant wouldn't even know existed, Or.

Think about something more personal, maybe an assistant that reads you recipes, but it uses curated audio samples to sound like a comforting, familiar voice, maybe even your grandmother's voice. If you had the recordings and it lets you navigate the cooking steps completely hands free, using just simple voice commands tailored to that specific.

Task, that would be amazing. It makes you wonder what kinds of unique, genuinely helpful or even just wonderfully quirky, and specific voice interfaces are still waiting to be built, especially when you start combining these foundational technologies tts ASR NLU dialogue management, device control in new and unexpected ways.

Exactly what's the potential beyond the mainstream assistance we interact with now? It definitely leaves you with something to think about.