audiodynamics.Dynamics DYN_TRANSIENT attack path: P4 ≠ S3 ≠ desktop on the same probe

[bdbarnett]

Found by the effects program's TransientShaper G5 hunt (audiocomponents effects/p2b-integration, tools tools/phase2_probes/transientshaper_digest_bisect.py and transientshaper_digest_bisect2.py), 2026-09-07, on firmware that reports the same build string on both boards. audioif is pinned at 2f6cbc3 and was not edited.

This is not audioif#55. That issue is boards agree, desktop differs on the baseline DYN_COMPRESS palette row. Here the two boards disagree with each other, and only on the transient attack (positive envelope-difference) path.

Boards

	ESP32-P4 (COM4)	ESP32-S3 (COM49)
os.uname().version	v1.28.0-dirty on 2026-09-07	v1.28.0-dirty on 2026-09-07
_build	ESP32_GENERIC_P4-C6_WIFI	ESP32_GENERIC_S3-SPIRAM_OCT

Symptom

tools/measure_effect_cost.py target rebuilt:TransientShaper@1, 128 blocks of the integer probe, 256-frame stereo at 48 kHz:

mpftp run -d COM4 /tmp/ts_repro.py --follow
ROW	rebuilt:TransientShaper@1	881.0	4.70	1.135	0.297	0.838	1776	0754b902fe5025a1

mpftp run -d COM49 /tmp/ts_repro.py --follow
ROW	rebuilt:TransientShaper@1	441.2	2.35	2.267	0.482	1.784	1808	a3942224c339ede3

PYTHONPATH=lib .venv/bin/python -c "import sys; sys.path.insert(0,'tools'); import measure_effect_cost as m; m.main('rebuilt:TransientShaper@1')"
ROW	rebuilt:TransientShaper@1	…	a7f7c4de0042a7cd

A second construction of the same target on each board reproduced the same digest. The bare probe is 4169efd90ecf44dd on all three.

Minimal reproduction (class not involved)

Same probe and digest window as the cost runner. One audiodynamics.Dynamics at the node's defaults (DYN_TRANSIENT, peak detector, transient_dual=False) with only attack_gain_db set:

import measure_effect_cost as m
import audiodynamics

def build(probe):
    node = audiodynamics.Dynamics(
        audiodynamics.DYN_TRANSIENT,
        sample_rate=m.SAMPLE_RATE,
        channel_count=m.CHANNELS)
    node.set(attack_gain_db=9.094488188976378)  # Snap Attack; f32 06831141 on every host
    node.play(probe.output)
    return node, (), (node,)

print(m.run(build, True)["digest"])

Host	digest (nodual+peak+att)
desktop CPython	64ef8393dbee988a
ESP32-P4	557c6bc78f3aa8c4
ESP32-S3	856f86d55a882edd

The class's own constructor options (transient_dual=True, detector="rms", rms_ms=3.0, sustain_fast_attack_ms=0.0) plus the same Attack give a different three-way split (988ebb97d751190e / 3082b8dcfd77385a / 3c23187048f0c180) that is byte-identical to transient_dual=False with those RMS options. Dual is not the splitter.

What agrees (so this is not "float differs between architectures" as a blanket)

Same tool, same boards, same session:

• Bare ctor (gains still 0): 4169efd90ecf44dd on all three (a wire).
• DYN_EXPAND + RMS + a threshold/ratio: 85887b7b83768fe4 on all three.
• DYN_TRANSIENT, RMS, transient_dual=False, sustain_gain_db=12 (the negative-difference / sustain path): 6ab77a94abff440e on all three.
• First eight 256-frame blocks of the attack-only render: identical on P4, S3 and desktop. S3 first differs at block 8; P4 and desktop still match through block 15 and diverge later in the 128-block window.
• The five Snap macro values as f32 are identical on P4 and S3. State is zeroed (audioif_dynamics_state_init / clear_extras). Buffer length is 1024 on every pull. No NaN/clip difference in the first block. A second run on each board matches the first.

The C that moves is audioif_dynamics.c:603-679: one-pole envelopes, audioif_dynamics_gain_to_db (logf) and audioif_dynamics_db_to_gain (expf) on the positive envelope difference, then a multiply by Attack. Coefficients are rebuilt every process via expf in audioif_dynamics_ms_to_coef. RISC-V P4 vs Xtensa S3 libm / FMA contraction is the remaining mechanism; it was not isolated below that.

Consequence

TransientShaper is one Dynamics and a set of node.set calls. The class is exonerated. A per-architecture accepted baseline for DYN_TRANSIENT attack, the same shape as #55 asks for the compress row, would close the board half of the class gate.

[bdbarnett]

Reproduced on current firmware and narrowed to one mechanism, which this issue left open ("RISC-V P4 vs Xtensa S3 libm / FMA contraction is the remaining mechanism; it was not isolated below that"). Measured today on both attached boards.

It survived the pin move

Both boards now run v1.29.0-dirty on 2026-09-09 (P4 ESP32_GENERIC_P4-PRE_REV3_C6_WIFI, S3 ESP32_GENERIC_S3-SPIRAM_OCT), not the v1.28.0 firmware this issue was filed against. Every digest reproduces exactly:

case	x86 desktop	ESP32-P4	ESP32-S3
bare (a wire)	4169efd90ecf44dd	4169efd90ecf44dd	4169efd90ecf44dd	all agree
nodual+peak+att	64ef8393dbee988a	557c6bc78f3aa8c4	856f86d55a882edd	three-way split
dual+rms+att	988ebb97d751190e	3082b8dcfd77385a	3c23187048f0c180	three-way split
nodual+rms+sustain	6ab77a94abff440e	6ab77a94abff440e	6ab77a94abff440e	all agree

libm is RULED OUT

MicroPython on both boards is single precision — 1e300 gives inf, 1.0/3.0 gives 0.33333334 — so math.log/math.exp/math.log10/math.sqrt there are logf/expf/log10f/sqrtf. Compared as raw 32-bit bit patterns over 17 log inputs (1e-6 … 100), 11 exp inputs (−9 … +1), and the same sets through log10f and sqrtf:

Every value is bit-identical on P4 and S3. So the RISC-V and Xtensa libm halves of the hypothesis are not the cause.

FMA contraction moves exactly this path, and nothing else

Rebuilt the CPython extension with CC="gcc -mfma -ffp-contract=fast" (263 vfmadd/vfmsub instructions against 0) and swapped only the .so, leaving every Python twin as installed:

case	plain x86	x86 with FMA
bare	4169efd9…	4169efd9… unchanged
nodual+peak+att	64ef8393…	35c603e85dd2d483 moved
dual+rms+att	988ebb97…	64b2aa16d6c7f0d3 moved
nodual+rms+sustain	6ab77a94…	6ab77a94… unchanged

That is precisely the boards' pattern: the wire and the sustain path are immune, both attack paths move. The FMA digests match neither board — expected, since where a compiler chooses to contract differs per backend — but the signature identifies the mechanism.

-mfma -ffp-contract=off emits zero FMA instructions and reproduces the plain digests exactly, so contraction is a controllable lever and not just an observation.

Two methodological notes, because the first attempt at this measured nothing: the audiocomponents venv imports an installed _audioif from site-packages, so rebuilding the checkout's .so changed no behaviour until the path was overridden — the same trap as audioif#22. And prepending the audioif checkout to PYTHONPATH also replaces the Python twins, which moved even the bare digest; only the .so may be swapped for this comparison to mean anything.

What would close it

If contraction is the whole of the P4/S3 difference, compiling src/shared/ with -ffp-contract=off on every target makes them agree and this closes as a fix rather than as a per-architecture baseline. That needs firmware built with the flag and flashed to both boards, which is the one step not yet taken.

Worth noting for whoever does: on the CMake ports the flag would go on usermod_mpaudio, which is an INTERFACE library, and its options propagate to the consuming target — i.e. to all of MicroPython, not just our sources. micropython.cmake:133-142 already documents that propagation trap for definitions. The flag needs scoping to our own translation units.

[bdbarnett]

Fixed, not baselined. The two boards now agree, which is this issue's subject — it opens by distinguishing itself from audioif#55: "This is not audioif#55. That issue is boards agree, desktop differs. Here the two boards disagree with each other." They no longer do.

Landed as 113531d, verified on freshly built and flashed firmware:

                     ESP32-P4            ESP32-S3
bare                 2b84dbd5784edd6a    2b84dbd5784edd6a
nodual+peak+att      c305c3c3b507d620    c305c3c3b507d620
dual+rms+att         06df738ac2283b43    06df738ac2283b43
nodual+rms+sustain   40be6e0df7a9ddb1    40be6e0df7a9ddb1

Both boards report AUDIOIF 0.3.0 v0.0.3-207-g113531d, matching git describe exactly — the marker added for audioif#55(a), which is why those digests are attributable at all.

Cause: fused multiply-add

a * b + c may be emitted as multiply-round-add-round, or as one fused instruction rounding once. Both legal, different in the last bit, and the choice is the compiler's. The static evidence said so before the boards confirmed it — same source file, two ESP toolchains:

xtensa-esp32s3-elf-gcc -O2    29 madd.s / msub.s
riscv32-esp-elf-gcc    -O2    30 fmadd.s / fmsub.s / fnm*

One #pragma GCC optimize("fp-contract=off") on src/shared/audioif_dynamics.c takes both to 0.

libm was eliminated, not assumed

This issue named "RISC-V P4 vs Xtensa S3 libm / FMA contraction" and said it "was not isolated below that". MicroPython on both boards is single precision (1e300 → inf, 1.0/3.0 → 0.33333334), so math.log/exp/log10/sqrt there are logf/expf/log10f/sqrtf. Compared as raw 32-bit patterns over 17 log inputs, 11 exp inputs and both through log10f/sqrtf: bit-identical on P4 and S3, and bit-identical to glibc on x86 — 0 of 28 values apart. Not libm, either half.

It costs nothing

	contraction ON	OFF
P4 (n=5)	0.7032 ms/block	0.7037	+0.08%
S3 (n=12)	median 1.4955, min 1.4948, mean 1.5076	median 1.5022, min 1.4848, mean 1.4994	+0.45% / −0.67% / −0.5%

The S3's sign flips with the estimator and by mean it is faster without contraction, so the effect is below the noise floor. An earlier read of 1.3–1.6% came from five samples and did not survive twelve.

Two things worth carrying forward

A baseline would have been the wrong answer. This issue's Consequence section proposed "a per-architecture accepted baseline for DYN_TRANSIENT attack". That would have enshrined a difference that had a free fix. Same caution applies to audioif#55(b): survey with contraction off before recording any baseline.

The comparison in this issue was never apples to apples. Once the revision marker existed it showed the boards and the desktop had been on different audioif revisions for this issue's whole life — visible because bare, the case described here as "a wire", moved when I flashed and then matched the checkout desktop exactly. The probe's material runs through audiomixer, which changed the same day. Every three-way digest as filed was comparing two different audioifs.

What moves elsewhere

The desktop still differs from both boards on the two attack cases, with contraction off everywhere and libm identical — a third mechanism, desktop-vs-board only, which is audioif#55's by this issue's own division. And the other 26 shared DSP files still contract, so per-node board disagreement remains possible: audioif#79, deliberately not swept here because it would move board digests for every float node and audiocomponents' cost table is pinned to them.