Firmware flow
Trigger SD playback from two microphone inputs
Selected playback branches from a Teensy audio firmware variant; the microphone levels and current time are read earlier in the loop.
The two input checks run in order and can both trigger during one loop iteration. Each eligible input stops its player if necessary, requests the corresponding WAV file and stores a new cooldown timestamp.
The checks use signal level, not rising-edge detection. A sustained input above threshold can retrigger after each cooldown. The return value from play() is not checked, so the calls establish playback requests rather than confirmed sound output.
Read the implementation
code.txt — microphone-triggered playback branches.
// Mic A triggers B.wav on Left output
if (lvlA > THRESHOLD && now - lastA >= COOLDOWN) {
Serial.println(">> Trigger: Mic A detected vibration → playing B.WAV on Left");
if (playA.isPlaying()) playA.stop();
playA.play("B.WAV");
lastA = now;
}
// Mic B triggers A.wav on Right output
if (lvlB > THRESHOLD && now - lastB >= COOLDOWN) {
Serial.println(">> Trigger: Mic B detected vibration → playing A.WAV on Right");
if (playB.isPlaying()) playB.stop();
playB.play("A.WAV");
lastB = now;
}Technical notes
Two playback paths
Mic A requests B.WAV on the left output; mic B requests A.WAV on the right. Each input has its own cooldown timestamp, and an eligible trigger stops any current playback on that player before requesting the file again.
Level and cooldown checks
The selected source uses a threshold of 100 and an 800-millisecond cooldown. These are level checks rather than rising-edge detection, so a sustained signal can retrigger after the interval. Playback success is not checked by the control loop.
Storage and startup limits
The sketch reads WAV files from SD and reports diagnostics over Serial; it does not implement SD logging or a UART command protocol. Startup waits for Serial and halts if SD initialization fails. Audio output and timing were not tested in this review.