Background
PR #26 raised the fast-tier --nbmake-timeout 900s → 1800s to stop intermittent CI timeouts. That's an interim fix; the root cause is still there.
Root cause
Tutorials/Signals - Frequency Analysis.ipynb has a teaching demo — "DFT by correlation" — implemented as a brute-force O(n²) sweep. The helper (notebook cell 7, calc_and_plot_xcorr_dft_with_ground_truth) defaults to xcorr_freq_step_size=None → a 1 Hz step across the full Nyquist range.
Two cells are pathologically slow because they run it on long, high-rate signals without a step override:
- the 11 kHz sine-wave chord cell (
SineWaveChord_..._11025Hz_mono.wav) — saved runtime ~2 min
- the real-audio cell (
HumanVoice-Hello..., loaded at 8 kHz) — ~6–14 s
On a slow/contended GitHub runner the 2-min cell crept past the old 900s cap → flaky failures. The same suite has been observed at ~3 min, ~16 min, and ~32 min purely from runner variance.
Proposed durable fix (low risk, no pedagogy loss)
Pass a coarser xcorr_freq_step_size (e.g. 5–10 Hz) to just those two cells. The helper already supports it and several other cells in the notebook already use it (e.g. xcorr_freq_step_size=10, 0.5). At a 0–5.5 kHz x-axis the plot is visually identical, the chord peaks (261–4186 Hz) are still clearly resolved, and the cells drop ~5–10× (≈2 min → ≈15 s). Then the timeout could even be lowered again.
Acceptance
Unrelated minor CI nit (drive-by)
Context: surfaced while resolving #6 (PR #25). Claude has a ready patch for the step-size change if wanted.
Background
PR #26 raised the fast-tier
--nbmake-timeout900s → 1800s to stop intermittent CI timeouts. That's an interim fix; the root cause is still there.Root cause
Tutorials/Signals - Frequency Analysis.ipynbhas a teaching demo — "DFT by correlation" — implemented as a brute-force O(n²) sweep. The helper (notebook cell 7,calc_and_plot_xcorr_dft_with_ground_truth) defaults toxcorr_freq_step_size=None→ a 1 Hz step across the full Nyquist range.Two cells are pathologically slow because they run it on long, high-rate signals without a step override:
SineWaveChord_..._11025Hz_mono.wav) — saved runtime ~2 minHumanVoice-Hello..., loaded at 8 kHz) — ~6–14 sOn a slow/contended GitHub runner the 2-min cell crept past the old 900s cap → flaky failures. The same suite has been observed at ~3 min, ~16 min, and ~32 min purely from runner variance.
Proposed durable fix (low risk, no pedagogy loss)
Pass a coarser
xcorr_freq_step_size(e.g. 5–10 Hz) to just those two cells. The helper already supports it and several other cells in the notebook already use it (e.g.xcorr_freq_step_size=10,0.5). At a 0–5.5 kHz x-axis the plot is visually identical, the chord peaks (261–4186 Hz) are still clearly resolved, and the cells drop ~5–10× (≈2 min → ≈15 s). Then the timeout could even be lowered again.Acceptance
--nbmake-timeoutback down once the cells are fast.Unrelated minor CI nit (drive-by)
actions/checkout@v4/actions/setup-python@v5are being forced onto Node 24. Bump action versions when convenient.Context: surfaced while resolving #6 (PR #25). Claude has a ready patch for the step-size change if wanted.