Audio Frame Time Budget Explorer¶
Run the Audio Frame Time Budget Explorer MicroSim Fullscreen
Embed This MicroSim¶
Place the following line in your website to include this MicroSim:
<iframe src="https://dmccreary.github.io/open-study-buddy/sims/audio-frame-budget-explorer/main.html" width="100%" height="552px" scrolling="no"></iframe>
Description¶
The microphone delivers one 2,048-byte frame every 40 ms into a ring buffer that holds about 9.77 frames (0.39 s). The main loop does P milliseconds of work and then reads one frame. If P is 40 ms or less the loop keeps up; if it is longer, a backlog grows by (P / 40 - 1) frames every pass until the ring overflows and audio is lost.
The graph shows the backlog after each pass against the ring capacity, and marks the pass and time of the first lost audio. In explore mode you move P from 10 to 100 ms. In the quiz you calculate, for six loop timings, how many seconds pass before audio is lost, or type "never". This is a model based on one board's measurement of the ring depth; the 130 ms timing is the measured full-screen update time from Chapter 5.
How to Use¶
The MicroSim opens in its starting state and nothing moves until you act.
- Start the 6 timings / Back to explore: Switch between the slider and the quiz.
- Answer box and Submit: Type seconds (within 0.1 s) or never. One attempt per timing.
- Next timing / See score: Move on after the feedback.
- Time per pass P slider: Explore only: 10 to 100 ms in steps of 0.1 ms, default 40.0 ms.
Lesson Plan¶
Learning Objective¶
The learner will examine 6 loop timings against the 40 ms frame budget to decide whether each keeps up with the microphone and, for those that do not, calculate the time until the first audio is lost, to within 0.1 s.
Bloom's Taxonomy level: Analyze (examine)
Audience and Duration¶
High school students (grades 9-12) building the Open Study Buddy; about 15 minutes.
Prerequisites¶
audio frame, ring buffer, frame time budget, backlog (all defined in the sections above this block). The model is stated in the Rules field and shown on screen.
Activities¶
- Exploration (5 min): Move P from 40.0 to 41.0 ms and then to 60 ms. Record how long each runs before audio is lost.
- Guided practice (5 min): For timing 3, write the growth per pass, divide the ring capacity by it, and multiply the pass count by 45 ms before submitting.
- Assessment (5 min): Complete all six timings. Mastery is 5 of 6 correct on the first attempt.
Common Misconceptions Addressed¶
(1) A loop that takes slightly longer than the frame is fine because the buffer is big. (2) A loop that is faster than the frame wastes audio. (3) The ring holds all the audio forever.
Discussion Questions¶
- A loop only 5 ms too slow still loses audio within 3.6 s. Why does a big ring not save it?
- Why does a loop faster than 40 ms not waste audio?
- What changes in the graph if the ring were twice as deep?
Assessment¶
The quiz inside the MicroSim is the evidence of mastery: each item is scored on the first attempt only, the correct answer and its reason are shown after every submission, and the final screen reports the score against the mastery threshold.
Specification¶
Full specification from Chapter 8
Type: microsim
**sim-id:** audio-frame-budget-explorer<br/>
**Library:** p5.js<br/>
**Status:** Specified<br/>
**Bloom Level:** Analyze<br/>
**Bloom Verb:** examine<br/>
**Learning Objective:** The learner will examine 6 loop timings against the 40 ms frame budget to decide whether each keeps up with the microphone and, for those that do not, calculate the time until the first audio is lost, to within 0.1 s.
**Prerequisites:** audio frame, ring buffer, frame time budget, backlog (all defined in the sections above this block). The model is stated in the Rules field and shown on screen.
**Evidence of Mastery:** For each of the 6 timings the learner types the seconds until the first sample is lost, or "never". An answer is correct when it equals "never" where the Answer column says never, or is within 0.1 s of the number in the Answer column. Mastery is 5 of 6 correct on the first attempt. Changing the exploration slider and watching the backlog is exploration, not evidence.
**Misconceptions:** (1) A loop that takes slightly longer than the frame is fine because the buffer is big. (2) A loop that is faster than the frame wastes audio. (3) The ring holds all the audio forever.
**Instructional Rationale:** Analyze-level examination requires the learner to relate parts of the system (the producer, the ring, the consumer) and reason about how a small rate difference accumulates. Using the same formula on six timings lets the learner see which one is the borderline case and why.
**Content:**
The model: one audio frame is 2,048 bytes and arrives every 40 ms. The ring holds 9.765625 frames (the depth measured in `03-ring-latency.py`, equal to 40,000 bytes at 8 bytes per sample time: 5,000 sample times, or 0.390625 s). Each pass of the loop takes P milliseconds of work and then reads one frame. If the loop is faster than 40 ms, it waits for the frame.
| # | Time per pass P (ms) | Answer | Why (shown as feedback) |
|---|---|---|---|
| 1 | 30 | never | The loop is faster than 40 ms, so it waits for each frame and the backlog stays at zero. |
| 2 | 40 | never | The loop exactly matches the audio rate, so there is no growth. |
| 3 | 45 | 3.56 | Growth 0.125 frames per pass, so it passes 9.77 frames on pass 79, and 79 x 45 ms = 3.56 s. |
| 4 | 50 | 2.0 | Growth 0.25 frames per pass, so it passes 9.77 on pass 40, and 40 x 50 ms = 2.0 s. |
| 5 | 60 | 1.2 | Growth 0.5 frames per pass, so it passes 9.77 on pass 20, and 20 x 60 ms = 1.2 s. |
| 6 | 130 | 0.65 | Growth 2.25 frames per pass, so it passes 9.77 on pass 5, and 5 x 130 ms = 0.65 s. |
For exploration the learner sets P from 10 to 100 ms in steps of 0.1 ms, default 40.0 ms. The sim shows the backlog in frames growing against the capacity of 9.765625 frames.
**Provenance:** The frame size and ring size are the values in `src/kits/study-buddy-base/config.py` (`FFT_SIZE`, `MIC_SAMPLE_RATE`, `MIC_BUFFER_BYTES`). The ring depth of 9.765625 frames comes from a measurement on the test board at 50 ms per pass (the delay stopped growing near 460 ms), and its cause is not confirmed. The model is a simplification, and the sim labels it "model, based on one board's measurement." The 130 ms value is the measured full-screen update time from Chapter 5.
**Rules:** Let T be the larger of P and 40 ms. The backlog after n passes is n x (T / 40 - 1) frames. The first sample is lost at the first whole number n for which the backlog is greater than 9.765625, and the time is n x T. If T equals 40, nothing is ever lost. Times are shown in seconds to two decimal places.
**Learner Activity:**
1. The learner moves the slider and watches the backlog line rise or stay flat against the capacity line.
2. The learner starts the 6 timings. Timing 1 is shown.
3. The learner types the seconds until the first loss, or "never," and submits.
4. The sim draws the backlog line for that timing and shows the Why text.
5. After timing 6, the sim shows the score. The learner should notice that a loop only 5 ms too slow still loses audio within 3.6 seconds.
**Feedback:** 6 timings, fixed order, one attempt each. Correct: "Correct: <Why>". Incorrect: "Not quite. The answer is <answer>: <Why>". The answer is revealed right after each submission, and a running score "n of 6" is shown.
**Starting State:** The slider is at 40.0 ms with the backlog flat at zero, and the question "How long can this loop run before audio is lost?"
**Chapter Anchors:** The chapter states that a frame is 512 samples, 2,048 bytes, and 40 ms; that the microphone ring was created with 40,000 bytes but measured about 9.8 frames (0.4 s) deep; and that a 50 ms pass loses audio after about 2.0 s while a 130 ms pass loses it after about 0.65 s.
References¶
- Circular buffer - Wikipedia - How a ring buffer holds data between a producer and a consumer.
- Real-time computing - Wikipedia - Deadlines and why missing one loses data.
- machine.I2S - MicroPython documentation - The ibuf ring buffer used by the microphone driver.