Add Mackie Onyx 400F (Echo Fireworks) support: recognition, publication, EFC control, duplex streaming

[ottendorfcipher]

Adds support for the Mackie Onyx 400F (Echo Fireworks production run; the 1200F is the same silicon). Developed and verified against an Onyx 400F behind an Apple Thunderbolt→FireWire adapter chain on macOS 26.6.2 / M3. Stacked on #101: the branch starts from that PR's head and reuses its Mackie profile and AV/C bypass plumbing, so the first 12 commits review there and the last 6 are this PR. Both branches are rebased onto current main; the three device-independent fixes that were found during this bring-up (local root enables its own cycle master, IRM re-issue of unanswered reads/locks, IT hardware-ring lap realignment) were merged separately in #117 and are no longer part of this PR. The 400F-only diff is the last six commits, or this compare view: ottendorfcipher/ASFireWire@onyx-820i-support...onyx-400f-support.

Verified on hardware

• Recognition + CoreAudio publication: 10-in / 10-out, 24-bit, 44.1 kHz, blocking mode; AM824 data block of 11 slots per direction (10 PCM + 1 MIDI, per snd-fireworks keep_resources).
• EFC control round-trips: HWINFO GET_CAPS ("Mackie" / "Onyx 400F", firmware 5.6.3, 10 channels each way at 1×/2×/4×, MIDI 1 in / 1 out), TRANSPORT SET_TX_MODE, HWCTL GET/SET_CLOCK (the unit was found at 48 kHz and moved to 44.1 kHz with a 150 ms settle).
• Duplex sessions: six consecutive CoreAudio start/stop cycles in one boot, StartIO to streaming in ~70 ms, FSM terminal Running / Idle with status 0 every time; 465k data-bearing packets accepted with zero rejected packets, zero geometry mismatches and zero invalid CIP headers.
• Playback: sustained music playback, audible on the unit's outputs, no TX underruns or silence fills.
• Capture: data-bearing packets accepted at the configured 11-slot stride (health verdict receivingData); a listening test on the capture side is still pending.
• IRM: every channel and bandwidth reservation released at stop, including the roughly 40% of stops where the 400F drops the response to the release read (handled by the IRM re-issue now on main via bus/irm/isoch/ohci: four device-independent fixes from #107 and #114 #117).
• Long sessions under host load: an 18-minute session turned choppy after three host stalls of 2–3 ms; each had silently slipped the transmit ring by one hardware ring. That is the IT ring-lap bug fixed on main via bus/irm/isoch/ohci: four device-independent fixes from #107 and #114 #117; with it, a deliberate stall burst while playing produced five IT lap sighted → IT ring lap: laps=1 skipped=48 corrections in seven seconds with the exposure lead unchanged, and steady state shows zero refused readings.

Change summary (one commit per step)

1. feat(audio) — Echo Fireworks backend: EFC codec (header/params framing, seqnum echo, HWINFO and HWCTL parameter layouts), EfcResponseMailbox plus a local-address handler for the host response window, EfcTransport (serial, 125 ms × 3), FireworksProtocol on the BeBoB/CMP base (SET_TX_MODE once per session, EFC-driven clock apply with settle and watchdog, HWINFO probe with a geometry gate), Onyx 400F recognition, Fireworks profile family, AVCDiscovery bypass publishing a static 10×10 @ 44.1 kHz nub, MackieOnyx400FProfile ADK geometry, factory dispatch. 1200F is recognition-only.
2. fix(audio) — review fixes before first hardware contact: IOLock-guarded transport with weak lifetime tokens in every bus/timer callback, bounded observer removal, MIDI slot geometry (DBS 11 per fireworks_stream.c), destructor cancellation, unarmable-timer handling.
3. fix(audio) — claim the 0xFCC0'8000'0000 EFC response window too: on first contact the unit acknowledged every command and answered within a millisecond, but at that address rather than the 0xECC0'8000'0000 that fireworks_transaction.c and snd-firewire-ctl-services document. The response address is firmware-stored (HWINFO flag bit 0 marks it changeable), so the mailbox claims both.
4. fix(audio) — start-clock pin: a first-ever start has no session clock and the coordinator's default requests 48 kHz, which the single-rate set refuses at Prepare (kIOReturnUnsupported); same mechanism as the Onyx-i and Duet pins.
5. fix(audio) — duplex profile: classify the 400F like the other CMP families (IRM-chosen channels, BeBoB start order, configured slot count as the capture stride) and without the pre-stream clock-lock gate. It had inherited the DICE-style gate and polled GET_CLOCK ~50 times for a lock a CMP device never reports.
6. fix(audio) — confirm a Fireworks duplex start without re-reading the plug registers: the base's oPCR read-back goes out in the same millisecond the IT context starts and the 400F never answers it, so the confirm stage waited out the 12 s sync bridge while both streams were already carrying data. Linux never re-reads after amdtp_domain_start; the connect-time compare-swaps already proved both plugs.

Design decisions flagged for review

• FireworksProtocol subclasses BeBoBProtocol, for the same reason MackieOnyxProtocol does in Add Mackie Onyx-i (Oxford) support: recognition, publication, asymmetric duplex streaming #101: the base's CMP connect/verify/teardown and plug-0 stream lifecycle are exactly what Fireworks streaming needs (fireworks_stream.c: CMP + AM824 blocking, SYT-unaware). Control differs — EFC over async block writes rather than FCP — so the protocol overrides Initialize, PrepareDuplex, ApplyClockConfig, ConfirmDuplexStart and ReadClockHealth and never touches the FCP path.
• No general fixes ride along any more. The three found during this bring-up (cycle master for a local root, IRM re-issue, IT ring-lap realignment) are on main via bus/irm/isoch/ohci: four device-independent fixes from #107 and #114 #117; this PR is device support only.
• Confirm without PCR read-back (commit 6) applies to this family only; BeBoB and Oxford devices keep the base's verify step.
• Static geometry, gated by HWINFO. The profile publishes 10 + 1 slots per direction at 44.1 kHz; Initialize and PrepareDuplex probe HWINFO and refuse to stream if the unit's 1× channel or MIDI port counts differ, so a 1200F cannot stream on the 400F's numbers.
• Rates are pinned to 44.1 kHz for the reason given in Add Mackie Onyx-i (Oxford) support: recognition, publication, asymmetric duplex streaming #101 (the ADK transport cannot reconfigure a live rate yet). SET_CLOCK is implemented and exercised on hardware, so widening the rate list should reduce to a one-line change once the reconfig path lands; 88.2/96 kHz additionally sit behind the driver-wide gate, and Linux notes firmware 4.6.0 reports a wrong DBS there (CIP_WRONG_DBS).
• Tests: 30 host tests for the EFC codec, mailbox and transport; 17 for FireworksProtocol including two confirm-stage cases that drive a real CMP connect through an address-keyed fake bus; and a DuplexStreamProfile pin for the CMP-driven classification. (The cycle-policy, IRM and ring-lap tests went upstream with bus/irm/isoch/ohci: four device-independent fixes from #107 and #114 #117.)

References (Linux snd-fireworks; snd-firewire-ctl-services protocols/fireworks; Apple IOFireWireFamily) were used as behavioral sources only, per the repository's reference policy; citations are in code comments. Local version-bump commits are excluded from this branch.

Not included

• Mixer and routing control (snd-firewire-ctl-services does this over EFC). The unit keeps its standalone DSP mixer state, so its last-saved routing applies.
• 1200F streaming: recognized by name only; needs its own geometry capture.
• Sample rates beyond 44.1 kHz (see above) and MIDI (the slot is carried on the wire; MIDIDriverKit is a project-wide TODO).
• Channel labels from the HWINFO physical groups (8 analog + 2 S/PDIF each way).
• Stop latency: when the 400F drops the release read, the stop path takes ~1.25 s (three deadline extensions before the IRM re-issue) instead of ~12 ms. Correct, just slow; trimming it would mean not extending the deadline for IRM reads.

[mrmidi]

Reviewed this alongside #101. Three commits here are device-independent and fix bugs that are live on hardware unrelated to the 400F, so I've cherry-picked them into #117 rather than let them wait on the Fireworks review:

• 35502389 local root enables its own cycle master
• b6720306 IRM re-issues timed-out reads/locks
• b5217056 IT hardware-ring lap detection

Two things worth telling you. First, the cycle-master one matters more than you probably knew — two other contributors hit the same wall bringing up MOTU hardware and worked around it in worse places (kDefaultLinkControl in one, the audio backend in the other). Yours is the only version that fixes it in the policy layer and re-arms per generation, so it's the only one that survives a bus reset. I checked IOFireWireController.cpp:3366-3367 and it's exactly as you describe.

Second — I reproduced the ring-lap bug on my own hardware. Focusrite Saffire Pro 24 DSP, completely different protocol family:

IT: Stopped. Stats: 1954500 pkts IRQs=324193 ringLaps=3 skipped=144 lostCycles=0
     refusedStamps=0/0/0 unrealignable=0 inFlightFallbacks=0

Could you rebase #101 and #107 onto main? Both are ~20 commits back, and #107 is stacked on #101 so it can't be reviewed independently. The rebase will drop those three as already-upstream. Mark them ready when you're happy and I'll review the device support on its own.

[ottendorfcipher]

Glad those turned out to be useful beyond the 400F, and the Saffire Pro 24 stop line was great to see. Both branches are rebased onto main and marked ready: #101 is 12 commits on current main, and #107 is 6 on top of it with the three #117 commits dropped as already upstream. #107 still needs the Mackie plumbing from #101, so it stays stacked for now; the 400F-only diff is the last six commits, or this compare view: ottendorfcipher/ASFireWire@onyx-820i-support...onyx-400f-support. Happy to rebase it flat as soon as #101 lands.