24f3002840/spank-mic

1. Overall shape

- This repository is a small, single-binary Go application (main.go) plus bundled MP3 assets.

- The runtime behavior is local and event-driven: listen to the microphone, detect a transient “slap-like” sound, then play a response sound.

2. Primary entrypoint

- main.go is the only code entrypoint visible in the tree, so the app is likely organized as one CLI process rather than multiple packages or services.

- The README shows the binary is launched directly from the terminal and controlled entirely by flags.

3. Input subsystem: microphone capture

- The key architectural change from the upstream project is that input comes from the Mac microphone instead of accelerometer/IOKit sensing.

- PortAudio is the external runtime dependency that provides cross-device audio input on macOS; this is why the project requires brew install portaudio.

- The data stream is therefore raw audio samples flowing from the microphone into the detection logic.

4. Detection subsystem: transient sound analysis

- The app listens for loud, short-lived audio spikes such as slaps, knocks, or claps.

- The README describes an adaptive noise floor and RMS/peak transient detection, so the detector likely maintains a moving baseline and compares current amplitude against it.

- This is the core decision boundary: sample stream in, “trigger” event out.

5. Response subsystem: audio playback

- When a trigger is detected, the program plays a response MP3.

- Playback is local and file-based; there is no remote service or network dependency in the architecture.

- The audio response path is separate from detection: one subsystem senses events, another chooses and plays sounds.

6. Sound library layout

- The audio/ directory is the content layer for responses.

- Each subdirectory represents a response mode or sound pack:

- audio/pain/ for default “ow” style reactions

- audio/sexy/ for escalating responses

- audio/halo/ for Halo-style death sounds

- audio/lizard/ for a minimal/custom variant with a single clip

- This is an asset boundary, not logic; the code likely enumerates files in these folders and selects among them.

7. Mode selection and escalation

- The README exposes CLI modes such as default, --sexy, --halo, --fast, --volume-scaling, and -c for custom sounds.

- Architecturally, this implies a configuration layer that selects a sound pack, sensitivity profile, cooldown timing, and optional intensity-based behavior.

- “Sexy” mode appears to use repeated detections as a state signal, escalating the response over time rather than treating every event identically.

8. Configuration boundaries

- User-controlled parameters appear to be handled through command-line flags rather than config files or a server API.

- Important runtime controls include sensitivity (--min-amplitude), cooldown/response pacing (--fast), and volume behavior (--volume-scaling).

- This means the application’s external surface area is the CLI, not a UI or network interface.

9. Platform and system dependency

- The project is explicitly macOS-oriented.

- Its main native dependency is PortAudio; there is no indication of a database, daemon, or cloud integration.

- The absence of sudo in the README is architecturally important: the microphone-based design removes the privileged system boundary that the original accelerometer approach needed.

10. Repository content vs runtime code

- Most of the repository is static media assets, not source code.

- go.mod and go.sum show a standard Go module layout, but the functional logic appears concentrated in one file.

- blog-复盘.md is documentation/postmortem content and does not appear to participate in the runtime path.

11. End-to-end data flow

- Microphone input is sampled through PortAudio.

- The detector computes loudness/transient features and updates an adaptive noise baseline.

- A trigger event selects a sound from the active pack.

- The selected MP3 is played locally through the audio output path.

- Optional mode logic changes which pack is used and how the selection/volume/cooldown behaves.

12. Diagram-friendly summary

- The architecture is best drawn as one local CLI process with four logical blocks: audio input, signal detection, response selection, and MP3 playback.

- External boundaries are limited to macOS microphone hardware, PortAudio, and the local filesystem holding bundled sound assets.