Audio, in reality, is a continuously varying pressure wave in air. What you did in this project is build a thin “measurement and summarization layer” on top of how that pressure wave gets turned into numbers. A few concrete, digestible takeaways from that perspective:

First: the microphone is a pressure-to-voltage sensor, and the ADC is a voltage-to-numbers machine.

A mic capsule moves with air pressure. That movement becomes a tiny analog voltage. The phone amplifies it (mic preamp), then an ADC samples that voltage at a fixed rate (typically 48,000 times/second in voice pipelines) and outputs a stream of numbers. Those numbers are what you see as PCM.

Second: PCM is just a time series of amplitudes.

Those samples are “snapshots” of the wave’s instantaneous amplitude at regular intervals. If you plotted the raw PCM values directly, you’d get the classic squiggly waveform—positive and negative values around zero. In most iOS audio paths you’ll see them as normalized floats (roughly in -1.0...+1.0), even if the underlying hardware is 16-bit or 24-bit integers.

Third: “bit depth” is how finely we can represent amplitude; “sample rate” is how often we take snapshots.

Sample rate (e.g., 48 kHz) sets the highest frequency you can represent without aliasing (Nyquist: ~24 kHz at 48 kHz).

Bit depth sets amplitude resolution and theoretical dynamic range (more bits → quieter details above the noise floor). In practice, phone mics and environments hit noise floors long before you hit theoretical limits.

Fourth: the recording waveform you’re building is not “the audio,” it’s a summary statistic of the audio.

Your UI bars are not plotting raw PCM. You’re computing an “envelope”: “how much energy is in this slice of time?” RMS is exactly that: it collapses hundreds/thousands of raw samples into one loudness-ish number for a window. That’s why the waveform looks stable and readable instead of a chaotic squiggle.

Fifth: decibels are why quiet speech still shows up.

Human hearing (and microphones) span huge dynamic range. Linear amplitude makes most speech look tiny until it’s loud. Converting RMS to dB and clamping (e.g., -60 dB to 0 dB) is essentially “compressing reality into something drawable.”

Sixth: “buffers” are just chunks of that sample stream.

LiveKit handing you AVAudioPCMBuffer is literally delivering a block of consecutive samples: “here are the next N snapshots.” Your renderer is tapping the stream. The reason you throttle to 60 Hz is not because audio is 60 Hz; it’s because you’re choosing how often you summarize the underlying 48 kHz stream for UI/storage.

Seventh: encoding is a separate phase from sampling.

If you write M4A/AAC or Opus, you’re not changing the fact that the source is PCM. You’re compressing it using psychoacoustic models and transform coding. The UI waveform you upload is neither PCM nor AAC—it’s metadata derived from PCM.

If you keep one mental model: audio in software is a very fast stream of numbers (PCM) representing a physical wave, and almost everything “product-visible” (waveforms, loudness meters, VAD signals) is a deliberate downsampled summary of that stream chosen for humans, not machines.

ChatGPT