DualSense Bluetooth haptics backlog: test guide¶

The changes tested in this guide were merged in PR #42 and ship in 5.0.30. The comparison baseline is the earlier 5.0.29 release; candidate version names below identify the builds used during hardware validation.

The same candidate also contains USB feedback corrections found during the maintainer's DEATHLOOP comparisons: editor motor tests after native output, and forwarding native waveform channels to the physical USB audio endpoint. These USB changes were absent from 5.0.29; the confirmed hardware results are recorded below.

This candidate addresses backlog behaviour investigated in upstream issue 124. The original test build did not reproduce the reporter's machine-specific stall; the release does not claim that report is conclusively resolved. No VIIPER or USB/IP update is required.

Confirmed hardware results — 2026-10-17¶

• The maintainer confirmed Test Heavy and Test Light work with a physical USB DualSense and virtual DualSense in the first USB feedback candidate.
• In 5.0.29-pr42-usb-feedback2 (source 2e02b44), the maintainer confirmed DEATHLOOP's previously missing intro vibration now works over USB. The log shows the native USB route starting at 17:01:56, then 1,087,200 source frames and 2,104 nonzero rear-channel blocks at 17:02:56. The initial one-second endpoint-enumeration wait resolved automatically. The older VIIPER speaker callback counters still show no USB callback delivery, as expected for this separate Windows audio route.
• The earlier Bluetooth candidate was reported to feel correct in-game, with native haptics active and no accumulating queue in its log. It did not reproduce the original reporter's stall, so it establishes compatibility rather than a demonstrated recovery fix.

The maintainer subsequently confirmed Bluetooth intro rumble and controller-speaker playback in the combined USB feedback candidate.

These confirmations cover the reported editor/intro cases and Bluetooth speaker playback; they do not establish every speaker/headset, reconnect or overload scenario in the acceptance checklist below.

Get ready¶

1. Keep your installed 5.0.29 copy available for comparison and back up its profiles/settings.
2. Download the x64 Portable artifact linked from the candidate PR's successful CI build. Extract the outer artifact download and then the contained application ZIP into a new folder. Use the complete package; replacing only DS4Windows.exe omits the matching application DLL/helper code.
3. Close the game and DS4Windows, quit VIIPER from its tray icon, then start the test copy. Run one DS4Windows copy at a time. Import a copy of your normal profile through Profiles. Keep the working release and existing drivers for this test.
4. Enable Settings > Updates & tools > Diagnostics > Verbose logging. Restart DS4Windows for each comparison run and save its log separately with the build and connection type in the filename. Use Open log in that same section to locate the log. A fresh application session makes the cumulative counters easier to interpret.
5. Use the same game, save/location, profile and graphics settings throughout. Choose a game which already gives native DualSense haptics on your PC, keeping its working virtual-controller selection (normally DualSense). Test locally first, without Sunshine/Moonlight. Desktop-audio-to-rumble effects alone do not exercise the same native-haptics source as the report.

Quick USB acceptance for the added corrections¶

1. Close the game, the released DS4Windows copy and VIIPER. Start the complete latest candidate portable package; keep Audio Haptics disabled. Connect the DualSense by USB and confirm (USB) (DualSense) in the log.
2. Use Emulated Controller: DualSense, keep Advanced > Feedback > Send game feedback to physical controller enabled, and save. Keep Steam Input disabled for DEATHLOOP. These native waveform checks do not use Xbox 360 emulation.
3. Under Advanced > Audio, leave USB DualSense speaker on automatic selection initially. The native haptics route uses the matching virtual controller's four-channel Windows endpoint and the physical USB controller's four-channel endpoint, even with Stream audio to controller off. Keep both Windows endpoints enabled and unmuted; leave your usual headphones/speakers selected for ordinary game sound.
4. Look for DualSense USB native haptics started. If the log says it is waiting for the physical USB audio endpoint, explicitly select the physical controller under USB DualSense speaker, save and retry. A stereo/downmixed endpoint is rejected, with a diagnostic, rather than playing vibration data as speaker sound.
5. With the game closed, try Test Heavy and Test Light separately; press again to stop. Both should work and stop promptly. Start DEATHLOOP, replay the stabbing/punching intro, then pause and repeat those editor tests after the game has sent native feedback. Stopping an editor test must allow subsequent game effects to work again.
6. With Stream audio to controller off, the intro should still produce native vibration without playing game sound through the built-in speaker. If you normally use speaker/headset streaming, enable it and check it alongside haptics, then disable it again. This must not switch on Audio Haptics.
7. Pause/resume and disconnect/reconnect USB once; confirm new effects return. Then do a short Bluetooth comparison and check the previously working intro, triggers and editor tests.

With verbose logging on, DualSense USB native haptics stats reports sourceFrames, nonzeroRearBlocks and bufferedBytes. During an active waveform scene, source frames and nonzero rear blocks should increase. USB now uses Windows four-channel capture/render for these actuator samples; speakerDelivered in the older VIIPER callback counters is not proof of USB delivery. Send the full log and describe which of the editor/game/speaker checks passed.

Comparison runs¶

If possible, repeat the released Bluetooth run after the candidate run. This helps distinguish an improvement from a transient change in radio conditions. Keep controller distance and normal background workload similar.

During each run:

• Repeat a short, recognisable event such as single shots, impacts or footsteps. Check whether the tactile response follows the event rather than a previous action.
• Alternate 30 seconds of activity with 10 seconds of doing nothing. After activity stops, effects should end normally rather than continue as a queue of delayed impacts.
• Include a pause/menu transition and return to play. Record the approximate time of any delay, missing effect, unexpected sustained vibration or recovery interruption.
• Test your usual controller-speaker or controller-headset audio if enabled. Listen for new pops/dropouts or disagreement between sound and haptics. The candidate retires obsolete rear-channel samples; it does not discard or reorder speaker/control packets to hide a backlog. Audio regression is a test failure even if haptics become fresher.
• Check adaptive triggers, lightbar and microphone mute if your profile/game uses them. After the main run, disconnect/reconnect Bluetooth once and confirm fresh effects return. Keep the profile unchanged during the timing comparison.

What to send back¶

Please provide the separate released/test-build logs, game name, whether native haptics worked over USB, controller model/firmware if known, Bluetooth adapter model, and approximate event times. A short video of the screen plus audible controller vibration may help compare repeatable events, but is optional and is not a calibrated latency measurement.

The test build adds these fields to verbose DualSense Bluetooth combined stream stats lines:

• hapticsRetired: obsolete rear-channel blocks retired during overload, including source publications which waited too long for space.
• hapticsRecoveries: consumer catch-up episodes after the age/expiry budget was exceeded.
• hapticsProducerWaitMaxMs: longest observed wait for shared-ring space.
• hapticsLatencyLimitMs=250: the candidate's software queue age threshold, not an end-to-end or over-the-air latency guarantee.

Keep the existing hapticsQueueDepth, hapticsQueueAgeMaxMs, helperCompletionMaxMs and pacerError fields. Queue-age and completion maxima are cumulative: an old peak alone does not show that latency is still rising. Counters may restart when a helper session is replaced. We will review the sequence of log entries, not one isolated maximum. The normal connection ms/Hz display measures report intervals and cannot establish haptic synchronisation.

Acceptance¶

A convincing result is reproducible delay in B, followed by a same-length C run without accumulating delayed effects, missing normal effects, repeated transport resets, or audio/control regressions. D must retain working USB feedback and exercise the added USB corrections above. Released 5.0.29 already lacked the maintainer's DEATHLOOP USB waveform effects, so matching that missing effect is not a successful candidate result. If neither released nor candidate Bluetooth runs reproduce delay, report that as a useful compatibility test, not proof of a fix. A one-off recovery that returns to normal is different from constant recovery/dropouts; report both accurately.

The candidate preserves FIFO playback through short interruptions. Beyond 250 ms of queue age it retires complete obsolete rear blocks until within a 50 ms catch-up target, preserving recent authored zero/stop blocks and lifecycle generation boundaries. A source waiting for capacity also has a 250 ms budget. Outstanding asynchronous HID writes which remain incomplete for over one second fault the existing transport owner and use its established cancellation/retirement/recovery path. Already-submitted writes are never overwritten or bypassed. These are software recovery budgets, not claims that Windows I/O or a suspended process can always execute within those times.

Disable verbose logging after testing. Return to 5.0.29 by closing the test copy and VIIPER, then launching the installed copy normally; your original profiles were not replaced.