[oneup03]

Problem

libctru numbers each channel's wave buffers 1 to 65535 and then starts again from 1 (ndspChnWaveBufAdd, which skips 0). dequeue() in firmware/voice.c plays the lowest id in the queue next, so it breaks at the wrap:

1. Just before the wrap, the voice holds, for example, current = 65532 and queue = [65533, 65534, 65535, 1].
2. When 65532 ends, dequeue() picks 1, the lowest id, ahead of 65533–65535.
3. In ndspiReadChnState, libctru walks its list up to the DSP's current id and marks 65533–65535 as done. On the DSP they stay queued, and because every later id is lower, they never play.
4. With three of the five slots taken for good, voice_queue() returns -1 for some of libctru's adds. libctru still counts those buffers as sent and marks them done once the voice moves past them, so they never play.

A channel that is fed without pause and never reset hits this after 65,535 buffers. From then on it uses up its stream faster than real time.

Where it showed up

rt64-3ds, the 3DS renderer and platform layer for several N64 recompilation ports (Goemon 64, Banjo-Kazooie, Donkey Kong 64, Dinosaur Planet), embeds OpenDSP 1.2.2. Each game's audio stream is one ndsp channel, fed with 60 buffers a second. On an Old 3DS log from Goemon 64:

• About 18 minutes in, which is about 65,500 buffers, the stream's consumption jumped from 44,095 to about 55,000 frames a second and stayed there.
• The queue's low point fell from about 2,590 frames to about 1,160.
• The game paces its music to that stream, so the music ran about a quarter fast for the rest of the session.

A simulation of libctru's bookkeeping against this dequeue() reproduces both changes. With buffers played in queue order instead, nothing changes at the wrap.

Fix

The ids are compared as a signed 16-bit distance, (s16)(a - b) < 0. Queued ids are always within a few of each other, so this gives the same order as before except across the wrap, where 1 now plays after 65535.

Testing

• A host-side check of the comparison: the wrap cases (65535 vs 1, 65533 vs 2) and ordinary ids order correctly.
• Not done: I couldn't rebuild firmware/opendsp.cdc, since I don't have the teak-llvm toolchain built, so this PR changes the source only. The image needs rebuilding, and the change hasn't run on hardware.
• Meanwhile rt64-3ds works around it on the host. Before a channel's ids wrap, it clears the channel with ndspChnWaveBufClear, which resets libctru's counter; the next buffer then carries the partial reset that empties the DSP's queue. It then queues the unplayed buffers again.

🤖 Generated with Claude Code