2
\$\begingroup\$

I'm a software engineer but have very little experience in EE. I'm looking to design a device that takes as input an analog audio signal and adds a chime if certain keywords are detected in the audio stream. The input is otherwise directly passed through to the output.

Assume we have a microcontroller that can raise a line high when the right keywords are detected. What would the rest of the circuit look like?

  • It seems like the simplest approach would be an analog circuit. Could we generate the chime with analog circuitry and just overlay it to the input?
  • Otherwise it seems that we would need to pass the input through an ADC, have the microcontroller add the chime digitally and pass it out through a DAC (or use a DSP dedicated to this task)
    • This will presumably add latency
    • Additionally with this approach power is required for the device to work - ideally the fail-case for the device being off/out of power is just the signal passing through untouched

There are likely other considerations I don't see yet. How would you approach this problem?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Do you expect to cover up the word with the chime? Or just add the chime without otherwise affecting the audio? One may require a fixed delay in order to get time to recognize words and cover up the sound. The other can just insert the chime when it has had time. \$\endgroup\$ Jan 29 at 21:27
  • \$\begingroup\$ Your assumption that an analog approach is simplest was correct many years ago, but not now. You can find speech keyword recognition examples that run on various low cost microcontrollers, such as a Raspberry Pi, and even some smaller, lower-power units. Try searching for "voice controlled home automation" for a start. Generating the chime tone is the trivial part - can be analog or digital. \$\endgroup\$ Jan 29 at 21:29
  • \$\begingroup\$ @MarkLeavitt an RPi is not a microcontroller, but a single-board computer carrying a set-top box SoC containing a Gigahertz-class multicore application processor. \$\endgroup\$ Jan 29 at 21:33
  • \$\begingroup\$ Generating the chime in an MCU is child's play compared to voice recognition so, I suggest that if you want a chime, you make the MCU produce it. \$\endgroup\$
    – Andy aka
    Jan 29 at 21:36
  • \$\begingroup\$ @periblepsis It would be adding the chime on top of the existing audio, playing at a lower volume that the main audio. For this application, it's not terribly important the chime be synced up perfectly to the keyword - it's fine if it's 1-2 seconds delayed. \$\endgroup\$ Jan 29 at 21:37

1 Answer 1

1
\$\begingroup\$

I'm a software engineer but have very little experience in EE. I'm looking to design a device that takes as input an analog audio signal and adds a chime if certain keywords are detected in the audio stream. The input is otherwise directly passed through to the output.

That's challenging as keyword detection needs compute, and even mathematically needs to have some latency. So, as long as your application works with a second or more of delay between utterance and reaction, that works.

Assume we have a microcontroller that can raise a line high when the right keywords are detected.

I'd seriously consider buying a significant stock of that microcontroller. Keyword detection with different speakers without prior per-speaker training takes compute power that puts this into the realm of application processors.

Your Alexa's reaction isn't based on a microcontroller, more on an application processor in the class of what entry-level smartphones sport.

What would the rest of the circuit look like?

Complicated.

It seems like the simplest approach would be an analog circuit.

Absolutely not. You need to process your signal digitally, so it's already there. Adding analog into this only complicates things.

Otherwise it seems that we would need to pass the input through an ADC, have the microcontroller add the chime digitally and pass it out through a DAC (or use a DSP dedicated to this task)

Yep.

This will presumably add latency

yes, but it's not the ADC nor the DAC that adds latency (at least not measurably), and you can do sub-perceptable digital audio passthrough on common application processors – there's simply no possibility mathematically nor physically to get a classification result before you processed the signal.

Additionally with this approach power is required for the device to work - ideally the fail-case for the device being off/out of power is just the signal passing through untouched.

You could implement that with a simple relay.

There are likely other considerations I don't see yet. How would you approach this problem?

as you're trying to build a complex embedded signal processing system, I'd try to understand the state-of-the-art open source voice assistants out there and how they detect keywords.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Extremely helpful, thank you! Picovoice advertises software that can be deployed to Arm Cortex-M microcontrollers, as do several other vendors. \$\endgroup\$ Jan 29 at 21:35
  • \$\begingroup\$ I was assuming you want an ad-hoc adjustable, rather large set of keywords. But yeah! If you know the keywords beforehand, and it's not many, and you have a PC-grade machine to train the classification model, a microcontroller can do it. (still, this classification is way more compute intense than superimposing a chime digitally) \$\endgroup\$ Jan 29 at 21:40
  • \$\begingroup\$ Yes that's right the keywords are known ahead of time and the model can be trained offline. Re: "What would the rest of the circuit look like?" - any tips there? \$\endgroup\$ Jan 29 at 21:42
  • \$\begingroup\$ uff, really depends. No, can't really give any hints. You will have to look into the microcontroller families that are capable of doing what you want, will have to define what kind of surrounding circuitry you need (battery/power control, actuators, interfaces,…), what your audio hardware looks like and what signal conditioning you need, and what your desired form factor ends up being. Frankly, that's like 3 or 4 prototypes further down the line. For now, I'd pick a microcontroller family, get an officially supported evaluation board for it, get your activation word detector running on that, \$\endgroup\$ Jan 29 at 21:45
  • \$\begingroup\$ and then move on to the next prototyping phase. Doing an audio device well takes a bit of fiddling, classically. \$\endgroup\$ Jan 29 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.