Teaching "How Computers Hear" to Hacker mode (ages 11–14)

Hook & Warm-Up

Open with the app's hook line, delivered as a genuine technical question rather than a rhetorical one:

"How does AI hear? It samples sound thousands of times per second, turning waves into numbers. Let's explore how speech recognition actually works."

Ask directly: "What does 'sampling thousands of times per second' actually mean — has anyone heard that term before, maybe from music production or audio editing?" A few students may know "sample rate" from music apps; build on that if so. Then frame the lesson: "Today we're not just naming that AI can 'hear' — we're tracing the actual pipeline from a sound wave to a piece of text on a screen, and where a phone's own AI stops and a much bigger one takes over."

One more framing question before opening the app, since it sets up the whole lesson's logic: "A photo is just a grid of pixel numbers, and a computer vision model finds patterns in that grid. If sound is also just a stream of numbers, what do you think the equivalent 'grid' looks like for audio?" Don't answer it yet — the spectrogram in Scene 1 is exactly that answer, and it lands better if the question is already sitting in the room when it shows up.

Main Activity

Work through the lesson's three scenes as a technical walkthrough, going one level deeper than the app's own text at each stop.

Scene 1 — Sound Waves 🌊. Establish the chain precisely: sound is air pressure vibrating; a microphone's diaphragm moves with that pressure and produces a continuous (analog) electrical signal; a computer then samples that signal — takes a discrete measurement — 44,100 times per second (44.1 kHz), the same rate used for CD-quality audio, to capture enough detail that the digital version is indistinguishable from the original wave. Ask: "Why not just measure it once? What would you lose?" (Guide toward: a wave's shape only exists across time — one measurement is a single number with no waveform at all.) Then introduce the spectrogram precisely: it's a transform of that sample stream into a two-dimensional representation — time on one axis, frequency on the other, intensity as color or brightness — which converts an audio recognition problem into an image recognition problem. This is worth stating explicitly: it's why AI "sees" sound rather than hearing it in any meaningful sense. Loop back to your framing question here: "This is the answer to the pixel-grid question — a spectrogram is sound's equivalent of an image, and the same broad family of pattern-recognition models that works on photos can be pointed at this instead."

Scene 2 — Speech Recognition 🗣️. Cover the wake-word / full-recognition split as a genuine architecture decision, not just a fact: "Hey Siri" runs on a small model on the device itself, trained to do exactly one narrow job — trigger on a specific short phrase — cheaply and with low latency, and critically, without needing to send continuous audio off the device. Ask: "Why would running that model on-device, instead of in the cloud, matter for both speed and privacy?" Then cover phoneme segmentation: speech gets broken into small sound units (phonemes) — write "H-EH-L-OW" for "Hello" — which get matched against learned patterns to reconstruct words. Note that Google Translate's spoken mode chains two separate AI systems: speech recognition into the source language, then translation, often followed by a third system (text-to-speech) to speak the result.

Scene 3 — Sound AI 🎵. Frame all four examples as instances of a model trained on labeled audio: Shazam builds a fingerprint from an audio clip's frequency peaks and searches it against a precomputed index of millions of songs — closer to a search problem than to speech recognition; the Merlin app is trained on thousands of labeled bird recordings to classify species from a call; Nest's sound detection is a classifier distinguishing categories of household sounds (bark vs. breaking glass); AirPods' active noise cancellation samples ambient sound and generates a phase-inverted waveform in real time to cancel it — worth noting this one is closer to signal processing than to the pattern-classification AI in the other three, though modern implementations increasingly use learned models to predict the cancellation signal. Have the class sort the four examples into two buckets on the board — "recognizing which known thing this is" versus "reacting to the shape of a signal in real time" — Shazam and Merlin fall in the first, noise cancellation in the second, and Nest's bark/glass detector is genuinely borderline (it has to react quickly like cancellation does, but its job is still classification, not signal generation).

Close with the app's summary line, and connect it explicitly back to the hook: "AI samples sound 44,100 times per second. It converts audio into visual spectrograms. Then AI models recognize speech from those patterns." Then have students complete the in-app practice round independently.

Discussion

• "If sampling more times per second gives more detail, why doesn't every device sample at the highest rate possible?" (Guide toward tradeoffs: file size, processing power, battery — and that speech itself doesn't need CD-quality detail to be recognized.)
• "What's the difference between what Shazam is doing and what a voice assistant is doing, even though both start with 'sample sound, then find a pattern'?" (Shazam is matching a fixed fingerprint against a fixed database; speech recognition is decoding open-ended, never-exactly-repeated speech.)
• "Why does running the wake-word model on-device instead of in the cloud matter for privacy, not just speed?" (Nothing has to leave the device until the wake word actually fires.)
• "Noise-canceling headphones react to sound in real time — what does that suggest about how fast this processing has to happen compared to, say, Shazam identifying a song?" (Noise cancellation has to happen in milliseconds continuously; song ID can take a couple of seconds and run once.)
• "Google Translate's spoken mode chains multiple AI systems together — speech recognition, translation, and text-to-speech. What happens to the final result if the very first system in that chain mishears a word?" (Guide toward: errors compound down the chain — a wrong word transcribed at the start gets translated and spoken as if it were correct, since each stage trusts the one before it.)
• "Bird-song ID and Shazam both classify audio against a large set of known categories. What would make one of these tasks harder than the other — more categories, more similar-sounding categories, or noisier real-world recording conditions?" (There's no single right answer, but a strong response should recognize that difficulty depends on more than category count — two very similar-sounding bird species, or a song playing faintly under crowd noise, are both genuinely harder cases than the raw number of categories suggests.)

Quiz Walkthrough

Wrap-Up & Extension

Close with: "Every voice feature you use — dictation, Shazam, a smart speaker — runs the same basic pipeline: sample the sound, turn it into a picture, and match that picture to patterns learned from enormous amounts of labeled audio. The differences are in what pattern is being matched and how much computing power the job needs." Add, if there's time for one more sentence: "The engineering question is almost never 'can AI recognize this sound' anymore — it's 'where should this particular piece of recognition run, and how much can we get away with computing on a small, battery-powered device.'"

Extension activity — "Design the Pipeline": In small groups, have students sketch a simple flowchart for one sound-AI product not covered in the lesson (a call-center system that detects an angry customer's tone, a music app that auto-tags a recording by genre, a security system that detects a smoke alarm going off in the background). Each flowchart should include: what gets sampled, whether it plausibly runs on-device or needs the cloud (and why), and what category the model is ultimately choosing between. Have groups present their pipeline and let the class question the on-device/cloud choice. This stretches the 10–15 minute core lesson into a full 35–40 minute period and applies the pipeline to genuinely new cases. Push groups to defend the on-device-vs-cloud call with a real tradeoff, not just a guess — a smoke-alarm detector, for instance, has a strong argument for staying on-device (it needs to work even if the home's internet is down, and the sound category is narrow enough that a small model can plausibly handle it), while a genre-tagging feature for a whole music library has a weaker case for running locally, since it isn't time-critical and can tolerate the delay of a round trip to a larger cloud model.