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.

This is a good moment to ask a question almost every Filipino student can answer from personal experience: "Has a voice assistant ever badly misheard you, maybe because of your accent, or because you switched between English and Tagalog mid-sentence?" Nearly every hand goes up — use that reaction to explain the actual mechanism, not just the phenomenon. The phoneme-matching step you just covered only works well for the phoneme patterns the model was trained on, and most commercial voice assistants are trained overwhelmingly on American and British English audio. Filipino-accented English realizes several phonemes differently — vowel sounds shift, stress patterns land in different places, certain consonant distinctions (like the "f"/"p" or "v"/"b" swap some speakers make) don't match the model's training data — so the phoneme-matching step is working against patterns it has seen far less of. Code-switching mid-sentence (Taglish) is a separate, compounding problem: most speech and language models assume one language is active at a time, so a sudden switch can break both the acoustic matching and whatever language-prediction step comes after it, since the model is now guessing the next word from a language distribution it wasn't expecting.

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).

Add a fifth, very Filipino example of this same classifier pattern: the Philippine BPO (call center) industry — one of the largest in the world — increasingly uses sound AI for call quality monitoring, listening to (or transcribing) recorded calls and classifying things like agent tone, compliance with a script, or how upset a caller sounds, instead of a human QA team sampling and listening to calls manually. Ask: "Given what we just covered about training data and accents, what could go wrong if a QA model like this was trained mostly on American call-center audio, then used to score Filipino agents speaking English with a Filipino accent?" (Guide toward: it could systematically misjudge tone, mis-transcribe words, or flag accented speech as "unclear" or "unprofessional" when it's neither — the same accent-mismatch problem from Scene 2, but now with real consequences for someone's job performance score.)

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.)
• "If a speech AI mishears Filipino-accented English or Taglish more often than American English, is that the model being 'bad,' or is it something more specific about how it was built?" (Guide toward: it's a training-data problem, not a mysterious flaw — the model reflects whatever accents and language patterns it saw the most of during training, which for most commercial systems skews heavily American and British.)
• "For a BPO call-QA model scoring agents' calls, what's the difference between the model being inaccurate and the model being unfair?" (Guide toward: inaccuracy affects everyone somewhat randomly; unfairness here would mean the errors aren't random — they systematically fall harder on Filipino-accented speakers because the training data underrepresented that accent, which is a bias problem, not just a noise problem.)

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 BPO call-QA system that scores an agent's tone and script compliance, 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 — for the call-QA option specifically, push the group to also flag where accent bias from Scene 3 could enter their pipeline. 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.