Put the container on the chip, and find the held bus costs 463 times the seam

ROADMAP P6c, FINDINGS 68. 78,125 B of a DLXP2's audio out of channel 3,
sample-exact, while the video channel fetches records off the same disc.

The two pieces 67.6 said were missing: the lump buffer (pg_afill/pg_afetch,
three slots and the minimum is unmeasured) and 67.2's remainder accumulator
(pg_apay). The capture prices what the accumulator avoided at 1.26 s of
lip-sync over the game, against 67.2's predicted 1.25.

The finding is the third piece, which nothing had named: the MSM6258 has no
starvation state, so the gap between a channel counting out and the next arm
is a held nibble pair driving the predictor. Stealing, the seam is 0.51 ms
over ten seconds because dma.i's new DM_HOOK services the chip from inside
the transfer wait -- 250,000 of 250,240 looks. Held, the 68000 is halted and
gets 369: every one of the ten lump boundaries has a seam, worst 72.8 ms,
2.31% of the audio. Identical bytes, different sound. 64.3 reaching the audio.

Two bugs, and no counter in the player could see either. Clearing DM_BARV does
not unchain a channel -- OCR bits 3-2 are what it obeys -- and the symptom is
POLL TIMEOUT on the lump and every record after it. And the refill ran one lump
ahead of its ring and overwrote the buffer the channel was reading: 11 of 11
armed, 11 fetched, no starve, and the sound wrong from 0.2 s in. Which is why
the gate is a WAV: verify_packed_audio.py walks the stream one delivered byte
at a time, because MAME's okim6258 resets the nibble select on every write and
a byte is two nibbles only 99.994% of the time.

check.sh ALL GREEN before (tmp/check_s36_start.log) and after
(tmp/check_s36_end.log), with the new stage.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

src/player/dma.i

@@ -126,6 +126,36 @@ DM_LEN   = $18524                       ; u32 bytes the channel was asked for
 ; DM_USE landed on ring.i's slot and turned a stage red (above).
 DM_BARV  = $18528                       ; u32 array base address, 0 = no chain
 DM_BTCV  = $1852C                       ; u32 array entry count (BTC)
+; ---- THE SERVICE HOOK, and it is the whole of what a SECOND consumer needs
+; from this file.  ROADMAP P6c.  A player that feeds ADPCM has to look at the
+; audio channel more often than once a frame: the MSM6258 has no FIFO, so the
+; instant its channel counts out the chip goes on replaying whatever byte its
+; data register still holds -- and at 12 fps a once-a-frame re-arm makes that
+; replay 90 ms long, which is not a gap, it is a buzz.
+;
+; THE ONLY PLACE A 68000 HAS TO SPARE IS INSIDE THIS WAIT.  In the STEALING
+; configuration the CPU goes round the loop below thousands of times per record
+; (measured: 1,100,520 trips over 120 frames) and every one of them is time the
+; disc is delivering and the CPU is not.  So the hook is called from there, and
+; the second consumer costs the video path nothing it was using.
+;
+; AND IN THE HELD CONFIGURATION THE HOOK CANNOT RUN AT ALL, which is not a bug
+; in it: a burst channel HALTS the 68000 (dma_transfer_start asserts
+; INPUT_LINE_HALT) and the CPU does not execute the loop, or anything else,
+; until the record has landed.  That asymmetry is the measurement -- FINDINGS
+; 64.3 showed a held channel costs the frame CLOCK half its ticks, and this is
+; the same fact reaching the audio.
+;
+; ZERO BY DEFAULT and every other front-end in this tree leaves it zero, so the
+; cost to them is a `move.l` and a `beq` per trip.  A mailbox that defaulted to
+; a new behaviour is how DM_USE landed on ring.i's slot (above).
+DM_HOOK  = $18530                       ; u32 0 = none, else a routine to call
+                                        ; on every trip round the transfer wait.
+                                        ; d0 is dead here and a0 is saved round
+                                        ; the call, so the hook may trash both;
+                                        ; it must preserve EVERYTHING else,
+                                        ; because sc_in_dma's own d3/d4/d5 and
+                                        ; scsi_read's a1 are live across it.
 DM_PATIENCE = 4000000                   ; the wait is bounded like every other
 
 ; ---------------------------------------------------------------- sc_in_dma
@@ -191,6 +221,13 @@ sc_in_dma:
         clr.l   DM_SPIN.l
         move.l  #DM_PATIENCE,d3
 .wait:  addq.l  #1,DM_SPIN.l
+        move.l  DM_HOOK.l,d0            ; the second consumer's slot -- see above
+        beq.s   .nohook
+        move.l  a0,-(sp)
+        movea.l d0,a0
+        jsr     (a0)
+        movea.l (sp)+,a0
+.nohook:
         move.b  DM_CSR,d4
         btst    #4,d4                   ; ERR
         bne.s   .err