audiobiquad.Biquad has no deinit() on the native builds, so ten audioif-tier filter and EQ classes cannot release one

[bdbarnett]

Stakes. Ten of the sixteen Phase 2 audioeffects classes are audioif
tier because they build audiobiquad.Biquad sections — BandPass,
CombFilter, DeEsser, DynamicEQ, GraphicEQ, HighPass, LowPass,
MultibandCompressor, Notch, ParametricEQ — and none of them can
release one on a board. The class gate's Tier 1 asks that deinit() release
every node the class built; on the two native builds
_component.Component.deinit() walks the class's node list, looks for
deinit with getattr(node, "deinit", None) and finds nothing to call. A
host that builds and tears down effects in a session leaks every Biquad it
ever made — GraphicEQ makes ten per instance, ParametricEQ eight,
LowPass three. Same shape as #58 (audioroute.Splitter) and #60
(audiodynamics.Dynamics); this is the widest of the three.

What the surface is. Measured this session, audiocomponents at
AUDIOIF_PIN 2f6cbc3, 2026-09-07:

$ .venv/bin/python -c "import audiobiquad; n = audiobiquad.Biquad(
      mode=audiobiquad.LOW_PASS, frequency=1000.0, Q=0.7071, gain_db=0.0,
      mix=0.0, sample_rate=48000, channel_count=2)
  print(hasattr(n,'deinit'), sorted(x for x in dir(n) if not x.startswith('_')))"
True  ['Q', 'bits_per_sample', 'channel_count', 'clear', 'coefficients',
       'deinit', 'frequency', 'gain_db', 'max_buffer_length', 'mix', 'mode',
       'play', 'playing', 'sample_rate', 'samples_signed', 'single_buffer',
       'stop']

$ cmods/bin/micropython -c "<the same>"
False ['Q', 'bits_per_sample', 'channel_count', 'clear', 'coefficients',
       'frequency', 'gain_db', 'mix', 'mode', 'play', 'playing',
       'sample_rate', 'stop']

$ cmods/bin/circuitpython-effects -c "<the same>"
False ['Q', 'bits_per_sample', 'channel_count', 'clear', 'coefficients',
       'frequency', 'gain_db', 'mix', 'mode', 'play', 'playing',
       'sample_rate', 'stop']

deinit, max_buffer_length, samples_signed and single_buffer exist on
the CPython target and on neither native build.

Why it is worse than a leak: it makes a gate row unfalsifiable. With no
deinit() to call, _deinited is never set, so the class's clean run and its
planted fault — a node deliberately left out of the deinit walk — give the
same answer, "0 live". Measured on LowPass
(tools/phase2_probes/lowpass_tier1_portable.py faults): the fault is RED on
CPython (1 of 3 nodes live) and GREEN on both native builds. A pack that
reported that green as a pass would be reporting absence as agreement.
LowPass's probe now prints n/a with this cause instead, and its evidence
pack carries the row as not met.

What would close it. audiobiquad.Biquad gaining deinit() on the
MicroPython and CircuitPython builds, with the same semantics as the CPython
target's: release the node's buffers, mark it deinitialised, and make a
subsequent pull raise rather than dump core (#59 is that second half).

Where this is recorded. docs/effects-phase2-gate-audit.md §3's G2 row
names it for five classes and says an issue is owed;
audiocomponents/docs/effects/LowPass-evidence.md §2 note ², §8 G2 and §11
carry the measurement above.

[bdbarnett]

Fixed in 2742489, together with #58 — the deinit and the guard had to land in one change.

The commit's Closes #58, #59, #60, #63 only closed the first: GitHub needs the keyword before each number. Closing the rest by hand.

What landed. deinit() on all thirteen node types that had none (every type audioif wrote itself, as against every type it ported from CircuitPython), and the deinitialised guard on audiosample_get_buffer / audiosample_reset_buffer — the funnel every pull and rewind in the palette passes through, whoever called it.

The crash surface was ten node types, not one. audiosample_mark_deinit() sets channel_count = 0 and a node's get_buffer divides by the channel count, so on the pre-change build pulling a released node dumped core for ten of the thirteen types that already had deinit():

node          before                  after
Mixer         SIGFPE  (core dumped)   raises
Chorus        SIGFPE  (core dumped)   raises
Echo          SIGFPE  (core dumped)   raises
MultiTapDelay SIGFPE  (core dumped)   raises
PitchShift    SIGFPE  (core dumped)   raises
Filter        SIGFPE  (core dumped)   raises
Distortion    SIGFPE  (core dumped)   raises
Phaser        SIGFPE  (core dumped)   raises
Freeverb      SIGFPE  (core dumped)   raises
SpeedChanger  SIGSEGV (core dumped)   raises
RawSample     returned stale audio    raises
Synthesizer   returned stale audio    raises

That is why the two halves could not be split: having deinit() without the guard was strictly more dangerous than having neither, and adding the twelve missing deinit()s on their own would have turned twelve safe types into twelve core dumps.

Gate. tests/parity/deinit_surface_probe.py, over all 25 node types, running unchanged on all three targets. --fault skips the deinit() call and must exit nonzero; CI runs the fault first and fails if it passes. The native half runs in clean-build.yml on a real MicroPython build.

No rendered bytes move: all 23 DSP probes byte-identical on MicroPython before and after.

[bdbarnett]

Correcting the record: this was closed on two of three targets, not three.

The commit closing it described tests/parity/deinit_surface_probe.py as "running unchanged on all three targets". The probe does run on all three. I only ran it on two — the CPython target and desktop MicroPython — and said so as though I had run three. Running it on the patched CircuitPython build, once that build existed later the same day, fails:

$ MICROPYPATH=. .../build-coverage/micropython tests/parity/deinit_surface_probe.py
  audiobiquad.Biquad has no deinit()
  audiodynamics.Dynamics has no deinit()
  audioroute.Splitter has no deinit()
  ...
exit=1

Measured: 0 of 13 type files under src/circuitpython_spike/shared-bindings/ contain MP_QSTR_deinit. audioif keeps a second, hand-written binding per module for CircuitPython, and it never received this work.

The MicroPython and CPython halves stand and are gated. The CircuitPython half is tracked in audioif#75, together with the two other instances of the same lag found the same day and the check that should have caught all three. Leaving this issue closed and the remaining work in #75 rather than reopening four issues for one cause.