Bluetooth DualSense speaker and advanced haptics delay or fail to start together

[vlue-c]

Bluetooth DualSense / DualSense Edge: speaker and advanced haptics cannot start together

I noticed this while playing Arknights: Endfield, which makes active use of both the DualSense controller speaker and advanced haptic feedback.

For example, opening the dial menu by holding LT can trigger a sound effect through the controller speaker and advanced haptics at the same time.

Observed behavior

With a Bluetooth-connected physical DualSense or DualSense Edge, when PadForge emulates either a virtual DualSense or a virtual DualSense Edge:

• Speaker-only output works.
• Advanced-haptics-only output works.
• However, when one feature starts immediately after the other, the newly requested feature can take roughly one second to become active.
• The same delay can occur in the opposite direction: speaker output may be delayed after haptics, and haptics may be delayed after speaker output.
• When speaker and advanced-haptics signals are sent at the same time, neither output is perceptible for approximately one second.
• The controller does not recover into simultaneous playback after that pause.
• Instead, output resumes only when a later speaker-only or haptics-only signal is received, and only that individual feature becomes active.

I observed this with both physical DualSense and DualSense Edge controllers, and with both DualSense and DualSense Edge virtual-controller personas.

Reproduction tool

I updated PersonaVerify so that it renders three distinct phases to the composite virtual audio endpoint:

1. Speaker only for 2.5 seconds
2. Advanced haptics only for 2.5 seconds
3. Speaker and advanced haptics together for 5 seconds

This makes it easier to distinguish normal sequential transitions from the simultaneous-output case.

Temporary local workaround

I used Codex to experiment with a local PadForge patch. I did not independently investigate the protocol or fully understand the existing implementation.

The workaround keeps the existing paths for individual features:

• Speaker only: normal Bluetooth 0x35 audio report
• Haptics only: existing Bluetooth 0x32 haptics report

But when both speaker and haptic data are active in the same tick, it sends a single 0x35 report containing:

• the 0x11 session header,
• the 0x12 advanced-haptics payload, and
• the 0x13 speaker/Opus payload.

With that local change, the final simultaneous phase in PersonaVerify works as expected, and I can also hear and feel speaker output and advanced haptics together in Arknights: Endfield.

I am sharing this mainly to report that the issue exists and to provide a reproducible symptom, affected configurations, and a possible direction for investigation. If useful, I can also share the relevant local code changes.

[Trihy]

Hi. BTW, how do you get haptics? Im using a wireless dualsense too, but doenst seem to get haptic. At least the real ones from the game. Do you have to enable any setting in padforge?

Im using Dualsense USB as emulated controller.

[vlue-c]

Hi, in my case, I only needed to enable "Hide devices from games" in the HidHide Driver settings to get haptic feedback.
I'm using PadForge v4.2.0 with HIDMaestro Driver v1.6.1, emulating "DualSense (PS5) -- Full."

If you have the same setup but it still doesn't work, make sure to launch PadForge first, wait until the device setup is fully completed, and only then start the game.

[Trihy]

Thanks. Need to recheck that. There is a little problem with built in hidhide. If you have standalone hidhide, every time you launch padforge it resets your hided controllers. Maybe could be a better solution, read the hided controller list from hidhide instead of writing the padforge one every time it launchs.

Will report later!

[hifihedgehog]

Thanks. Need to recheck that. There is a little problem with built in hidhide. If you have standalone hidhide, every time you launch padforge it resets your hided controllers. Maybe could be a better solution, read the hided controller list from hidhide instead of writing the padforge one every time it launchs.

Will report later!

@Trihy, this is by design, not a reset. PadForge owns the hide states it manages: at launch it applies exactly what you configured on each device's "Hide from games (HidHide)" toggle, so the app's settings are always the truth of what is hidden. Reading the standalone tool's list back in would invert that. Your toggles inside PadForge would then silently disagree with what the driver is actually doing, which is the kind of state drift we deliberately keep out.

The behavior you are after already exists as a setting. Turn on Keep devices cloaked between launches under Settings. That persists the HidHide cloaks across PadForge sessions instead of releasing them, precisely for setups where something else scans for controllers while PadForge is closed. It is off by default because most users expect their controllers back the moment PadForge exits.

So manage hiding from inside PadForge, and check that option if you want the cloaks to outlive the app. With that set, nothing gets unhidden on launch or exit.

[Trihy]

Thanks.

Tried again and something not working here. I selected wireless controller on windows audio output.

Dualsense (PS5) full as emulated pad. didnt touch any other setting at all.

Started Ratchet, sounds play on dualsense speaker.. Main menu, as soon as I go in game, audio stop playing. And there are no haptics. Adaptive trigers works.

Tried to swap to TV audio output then started to get some rumble, but doesnt look like haptic. For haptic is mandatory selecting wireless controller as audio output? There is a way to get specific games sound on speaker and not complete system audio?

Tried a clean padforge but didnt help to get haptic.

Did another test, leave spotify playing on dualsense speaker on dualsense (PS5) full. Launched Ratchet, after loading save, sound stopped, in game no haptics. After closing the game, sound (spotify) returned to dualsense speaker. I guess game is writing some report padforge is not interpreting correctly.

[Jobima1st]

I think I have similar problem, whether Bluetooth-connected or usb-connected physical DualSense, when PadForge emulates a virtual "DualSense Full" with GTA V E, the delay become worst as you play and the controller will continues doing the delayed advanced haptics and adaptive triggers even if you close the game!

[Trihy]

I noticed that too. I thought it was some kind of ghost input for accumulated errors. But not sure. I can clearly hear the triggers "click" noise (of swapping trigger effects) after the game was closed.

[hifihedgehog]

@vlue-c, this is a real bug, your diagnosis is right, and the direction you found is the correct one. Fixed in 81140f17.

What was wrong

Both reports carry the packet 0x11 audio session header, and the pad tracks one session. PadForge ran a separate rolling packet counter and sequence nibble for each report id, on the theory that the firmware tracks a sequence per report id. It does not. With one stream live the counter is monotonic and everything works, which is exactly why speaker-only and haptics-only were both fine. With both live, that single session saw a counter jumping back and forth, and the pad did what it does with a discontinuous stream: went quiet, then resynced onto whichever stream kept talking. Hence the one-second gap and the recovery into only one feature.

PadForge already had this failure recorded one level down. An early cut sent the same frame on both the speaker and headset lanes as two 0x35 reports sharing one counter, each lane saw the sequence advance by two, and the audio came out garbled. The note in the source ends "One report id gets ONE stream, full stop." The rule was right and the unit it was applied to was wrong. It is one session, not one report id.

The reasoning that split the counters in the first place cited dualsense-bt-haptics running an independent counter for its 0x32s beside outputSeq for 0x31. That was never the analogous case: 0x31 is the input state report and carries no 0x11 header at all.

What changed

One session, one counter pair. The haptic stream's private sequence and packet counter are gone. Both lanes, and the mic open/close toggle that also carries a 0x11 header, now advance the same pair.

A tick with both payloads sends one report. Speaker plus haptics in the same tick is now a single 0x35 chaining 0x11 + 0x12 + the audio lane packet, which is your patch's shape. Ticks carrying only one payload are untouched, so the paths that already worked keep their proven wire format.

Your instinct that this was the right shape holds up against the references, which is worth spelling out since you mentioned you had not dug into the protocol:

• dualsense-bt-haptics/Program.cs:172 records that the carrier depends on the packet id rather than the report id, and that 0x32 and 0x35 are interchangeable. So one report carrying both packets is not a trick, it is the grammar.
• DualSenseY-v2/source/audioPassthrough.cpp:343-400 models a packet as a sized TLV (pid:6, unk:1, sized:1, then a length, then the payload) and builds its report by appending packets at computed offsets. Chaining a third packet is what that structure is for.
• The same dualsense-bt-haptics file has a commented-out sketch that chains one more packet at data[77], immediately after the 64-byte 0x12 payload. That is byte for byte where the audio packet lands in the combined report.

Ordering follows what you tested: session header, actuators, then audio.

Evidence Status

Confirmed. The wire format is pinned by five new tests covering the packet chain and its offsets, both payloads surviving intact (the Opus frame is not clipped by the actuator block sitting ahead of it), the headset lane and mic-session byte, CRC coverage over the audio payload, and the signal verdict that drives the silence gate. Each was mutation-verified against a wrong chain offset. Full suite 3,388 green, zero warnings.

Hypothesized. That this removes the stall on hardware. The mechanism matches your symptoms exactly and the fix is the shape you already validated on your pad, but the change as committed has not run on a physical DualSense here.

Unverified. Whether anything else shares that session in a way this misses, for example a game driving haptics while the mic toggle retries.

---

@Jobima1st and @Trihy, the growing delay that keeps running after the game exits is a separate report and this change does not claim to fix it. I checked the two places a backlog could accumulate on that path, and neither can grow without bound: the actuator ring resynchronises to a 20 ms cushion once it drifts past 250 ms, and the Bluetooth write pool has eight slots and drops a frame rather than queueing when it saturates. Adaptive triggers continuing after exit also points somewhere other than the audio session, since triggers do not ride it at all. It needs its own investigation rather than being folded into this one, and the fact that it happens on USB as well as Bluetooth is a useful discriminator, since the session grammar here is Bluetooth-only.

@Trihy, the speaker going silent when Ratchet moves from the menu into gameplay is also its own thing. Worth keeping separate from the two above until there is something concrete tying them together.

[Trihy]

Hi. Thanks for new build. Maybe thats not necessary. Tried new build and haptics are now working. Same ratchet game. Only change was update padforge. Probably in game turned on the adaptive triggers and thas was causing speaker go mute.

Only remains ghost adaptive trigger, which seems to go crazy in game too. ie after exiting a race in F1 22. led bar goes somehow crazy too. That could be a bad report mode when having speaker sound. But leave that for other thread.

[hifihedgehog]

@Trihy, thanks for coming back with the result. That is the confirmation this needed: the fix was verified on vlue-c's hardware as a patch before it shipped, and yours is the first report of the shipped build working on a second machine and a different game.

Your earlier symptom turns out to be the same bug, not a separate one, and your own guess in that last message is right.

You reported the speaker playing in the menu and going silent the moment you reached gameplay, with Spotify behaving the same way and coming back when the game closed. That is exactly what the session collision looks like from the speaker's side. In the menu only one stream was live, so its counter was monotonic and everything worked. Entering gameplay the game began driving the actuators, the second stream joined with its own counter, and the one audio session the pad tracks saw a counter jumping back and forth. The pad went quiet and then resynced onto whichever stream kept talking. So "the speaker stops when I go in game" and "haptics and speaker cannot start together" were one defect seen from two sides, which is why the same build fixed both without anything else changing.

That also means the earlier note in this thread, where I split your speaker report off as its own separate thing, was wrong. It was the same root cause and the fix covers it.

The remaining item

@Jobima1st's report, that the lag grows over a session and the controller keeps acting after the game is closed, is still open and is being tracked here in this thread.

Two things have changed on that since the last update.

The first is that a plain reading of the queue no longer settles it. The effect lane is a bounded 64-slot queue that drops rather than grows, so it cannot accumulate without limit, which is what I said earlier. What that reasoning does not cover is how long each write takes when a Bluetooth link is also carrying an audio stream, and that is measurable rather than arguable.

So the second change is instrumentation. The build now carries a per-second effect-lane trace behind the existing diagnostic switch, recording what the game produced, what was refused, what actually reached the pad, how much is still queued, the worst single write in milliseconds, and how long since the game last wrote. Those fields separate the candidates instead of ranking them by plausibility: a queue depth that climbs with slow writes is transport backpressure, writes continuing while the game has gone quiet is a backlog draining, and both quiet while the pad still acts means the writer is somewhere else entirely.

One piece of context worth stating plainly, because it shapes what a fix can look like. Adaptive trigger programs are stateful on the real firmware: a program is set once and the pad holds it until something overwrites it. PadForge deliberately stands down and leaves that state alone when it is not authoring the triggers itself, so that a program written by something else survives instead of being stamped over a second later. That behaviour was itself the fix for a hardware-reported problem last August. So "make it clear the triggers on exit" is not a free change, and any fix here has to keep that guarantee intact rather than trade one report for the other.

Evidence Status

Confirmed. The audio session fix works on hardware, now on two machines and three games (@vlue-c's patch on his pad, @Trihy on the shipped build in Ratchet & Clank). The effect lane's queue is bounded at 64 with a drop-on-full policy. Adaptive trigger state is latched in DS5 firmware and PadForge's non-assertion when idle is deliberate.

Hypothesized. That link contention between the audio stream and the effect writes explains the growing lag. The mechanism fits the reports and is now measurable, but it has not been measured.

Unverified. Whether the post-exit behaviour is one cause or two, since a trigger held by firmware and a trigger being rewritten feel identical from the outside.

[vlue-c]

Thanks for reading through the report, analyzing it, and putting together the patch.

For reference, my test setup was:

• Dev build: PadForge_r3183@81140f1.zip
• Controller: DualSense Edge
• Connection: Bluetooth
• Emulation mode: DualSense (PS5) -- Full
• Game: Arknights: Endfield

With this setup, I can confirm that haptic feedback and the controller speaker work correctly at the same time.

I also tested recording through NVIDIA's recording feature. While haptics and the controller speaker were both active in-game, microphone recording through the DualSense Edge also worked correctly.

I wasn't able to fully verify the behavior of the mic mute button, though. While haptics + speaker + mic were all active, pressing the mute button did mute the microphone, but pressing it again did not unmute it.

This looks more like a game-side issue or an unimplemented feature than a PadForge bug. The reason I suspect that is that, on the desktop, pressing the DualSense Edge mute button does not appear to do anything at all.

So at least from my hardware test, the shared audio session fix is working correctly with haptics + speaker + microphone recording active together.

My issue is resolved, but I’ll left the thread open since the other issue identified here is still being tested.

[hifihedgehog]

@vlue-c, thank you for going back and testing it properly, and for listing the setup. That detail is what makes the result usable.

Your run covers ground the other confirmation does not. You are on a DualSense Edge over Bluetooth, where the other hardware report was a standard DualSense. Different pad, and the Edge carries a different report length, so between the two reports the fix is now confirmed on both members of the family rather than on one pad twice.

Why the microphone test is the most valuable part

Recording through the pad while haptics and the speaker were both live is a stronger check than it looks, and it is worth explaining what it actually proved.

The microphone is not a separate channel that happens to run alongside. The mic session command lives in the same packet 0x11 header the speaker and the actuator packets carry, in the first payload byte. So the bug this thread is about, two lanes each running their own counter into one session, sits directly underneath the microphone as well.

There is a specific trap there that your test clears. That header byte is not latched: a steady "close" value in the audio stream will re-close a microphone that was just opened. That was found here in July, when rendering audio silenced the capture endpoint outright, and the mic-session byte had to be made to track the live session on every audio report. Your result, with all three running at once and capture still arriving, is the case that would have caught it again if the combined report had got it wrong.

So the fix is confirmed for speaker, actuators and microphone sharing one session, which is the whole surface it touches.

The mute button

Your reading is right, and the reason is worth spelling out.

PadForge forwards that button and does not act on it. The physical mute button arrives as SDL's misc1, PadForge maps it to the virtual pad's mic-mute slot, and the game sees a mute button being pressed exactly as it would from a real DualSense. PadForge itself never mutes anything at that moment.

On the audio side PadForge mirrors the host's mute rather than inventing one. When Windows or an application mutes the persona's microphone endpoint, the control message arrives and PadForge takes the gain to zero. Unmuting is the same message in reverse. So if something muted and then never sent the unmute, PadForge will faithfully keep reporting silence, because from its side nothing has said otherwise.

That also explains the desktop behaviour you noticed. On a PS5 the console owns that button and performs the mute itself. On a PC there is no equivalent authority: nothing in Windows listens for a DualSense mute button by default, so outside an application that implements it the button genuinely does nothing. What you saw in the game was most likely the title acting on the button on its first press and not implementing the toggle back, which matches your own conclusion.

One practical note, since it is a fair thing to want. There is no built in "toggle microphone mute" action to bind it to, and Windows has no universal microphone mute key the way it has one for speaker volume. The usual route is to bind the mute button to whatever push to mute or mute toggle hotkey your recording or chat application exposes, which puts the toggle in the hands of the thing that actually owns the microphone.

Evidence Status

Confirmed. Speaker, actuators and microphone all working together on a DualSense Edge over Bluetooth with the composite persona, on the shipped fix, reported on hardware. Combined with the standard DualSense report earlier in this thread, the session fix is confirmed on both pads in the family.

Unverified. Everything about the mute button beyond PadForge's own behaviour. What the game does with the press is outside this application, and PadForge's part in that chain (forwarding the button, mirroring the host's mute) is doing what it is supposed to.

Thanks again for the report, the reproduction tool, and the retest. All three were what made this a short investigation instead of a long one.

[vlue-c]

Likewise, thank you for developing and maintaining such a useful tool. I really appreciate the work you put into PadForge, and I'll keep enjoying using it!

[hifihedgehog]

@Jobima1st, a request, and some context for why.

You reported that the delay grows as you play, and that the controller keeps running advanced haptics and adaptive triggers after the game is closed, on a virtual DualSense Full with GTA V Enhanced.

Your report landed about five hours before the fix in this thread was posted, so everything you saw was on the older build. That matters here, because the defect that was fixed was two audio streams each running their own counter into the one session the pad tracks, which put roughly twice the traffic on the Bluetooth link whenever the speaker and the haptics were both live. A tick that carries both now goes out as a single report instead of two.

Since then this has been retested on the current build by two people, on a standard DualSense and on a DualSense Edge, across three games, and neither sees a growing delay. It has also been tested here directly and does not reproduce.

So the question is simply whether it still happens for you.

If you have a chance to run the current dev build, anything at or after the commit referenced above, we would like to know which of these you get:

• the delay is gone
• the delay is still there, and how long it takes to become noticeable
• something changed but it is not fixed

Any of the three is useful. A "still happening" answer is the one that would keep this open, and it would come with your GTA V Enhanced setup attached, which is the configuration nobody else here has tested.

One note in case it saves you time. If the controller feels stiff or keeps clicking on the triggers after a game closes, that part is expected and is not a fault. Adaptive trigger programs are held in the controller's own firmware and stay loaded until something replaces them, so a game that is closed while an effect is active leaves that effect in the pad. The Weapon and Vibration effects click when you pull the trigger by design, so a latched one keeps clicking every time you touch it. That is the same on a real DualSense with no PadForge involved. Setting an adaptive trigger mode in PadForge and setting it back to Off will clear it.

The part we are asking about is only the growing delay.

[Jobima1st]

Unfortunately, its

the delay is still there, and how long it takes to become noticeable

it's noticeable as soon as I load my save and take a car, the delay around 1 min after playing for 3 min (These figures are estimates)

[Trihy]

Worth mention not every BT can handle a full dualsense. On my top list for worst bandwidth intel ones and some generic ones.

[Jobima1st]

Worth mention not every BT can handle a full dualsense.

my Bt is intel 5.1, but the original problem happen even with the usb

[Jobima1st]

Worth mention not every BT can handle a full dualsense.

the original problem happen even with the usb

still same (maybe a bit better than BT), of course, direct usb without PadForge does not have these problems

[hifihedgehog]

@Jobima1st, that log was worth more than everything reasoned about this lane so far. It found a real defect, and it killed my own explanation from the previous message. Both are worth spelling out.

What the trace measured

The game drives this lane at 18,000 to 19,600 effect packets per second, sustained for tens of seconds at a time. The assumption written into this code is 30 to 60 Hz. So the first thing your log establishes is that the entire design premise here was off by a factor of several hundred, which nothing short of a measurement was ever going to reveal.

My explanation was wrong. I said the delay came from a Bluetooth link that could not carry the write rate, with the backlog forming below the app in the operating system. Your trace reports the slowest single write to the controller in each second, and across the whole session it never exceeds 0.3 milliseconds. The link is not saturated, and it was never the problem. That hypothesis is dead and the fix built on it was addressing something real, but not for the reason I gave.

@Trihy's point about Bluetooth adapters is a fair one in general, and on a different report it would be the first thing to check. It does not fit this one, and @Jobima1st has the data that settles it: the same delay appears over USB. A bandwidth story cannot survive a change of transport. What the trace found can, because it is not about the link at all.

Two other things the log rules out, both worth knowing:

• The audio lane was completely idle for your whole session, so nothing was competing for the radio.
• The input engine held 1000 to 1001 Hz throughout, with a single stall of 139 ms during startup before the game was running. So PadForge's polling was not degrading over the session either.

What it found instead

The numbers do not add up, and the gap is the bug. About 18,000 packets arrive per second. About 7,550 are accounted for, either superseded on purpose or written to the pad. The drop counter reads zero the entire time while the queue depth sits pinned at its limit.

Roughly 10,500 packets per second were disappearing, and the queue was eating them.

The lane used a bounded queue set to discard the newest item when full, on the belief, written in a comment, that a refused write reports itself as refused so the code could release the memory it had reserved for that packet. That is not how it behaves. It accepts the write, reports success, and throws the item away. So every discarded packet leaked its reserved buffer, the allocator kept handing out fresh ones, and at your title's rate that is around ten thousand leaked allocations per second feeding straight into garbage collection. That is exactly the kind of load that reads as stutter and as things gradually falling behind.

Your observations line up with it. The LED feeds lagging alongside the triggers and haptics fits, because the lightbar rides the same payload as the trigger programs. Indiana Jones showing some of it fits better than the earlier "one badly behaved title" story did. And crucially, so does USB behaving the same as Bluetooth: memory churn does not care which cable or radio the packet eventually leaves by, which is exactly why your USB result is the strongest single piece of evidence in this thread for where the fault actually sits.

What changed

Effect payloads are state, so exactly one is ever worth holding. The queue is gone, replaced by a single slot: a new payload displaces the previous one and the memory for the displaced one is released at that instant, by the code that displaced it. Nothing can be silently discarded and nothing can leak, at any rate a game cares to write.

Vendor commands keep a real queue, because those are events where order and count matter, and it now uses a mode that actually reports a full queue so the same release can happen there.

Two tests pin the queue behaviour that was assumed rather than checked, so this particular belief cannot come back quietly.

Where that leaves your delay

The lane's own contribution to latency is now at most the 8 millisecond pacing floor plus one write, and a write measures a tenth of a millisecond in your trace. If a delay of anything like a second survives on this build, it is no longer inside this dispatcher, and the next place to look is between the game and PadForge rather than between PadForge and the controller.

The same trace answers that too, so if it is still there, the log from the new build tells us directly. If instead you notice the skipping more than the delay now, that is the pacing floor and it is a single number that can be relaxed, now that we know writes are cheap.

Thank you for running it. Every previous round in this thread was inference, and one attached file replaced all of it.

[hifihedgehog]

@Jobima1st, that is the result that matters. The delay was the part with a real defect behind it, and "feels like using without using PadForge" is the bar it needed to clear.

The skipping you still hear is a different thing, and it is not a bug so much as a number I picked while wrong about why the delay existed. It is worth explaining, because the two have opposite causes.

While the delay was being blamed on a saturated link, the fix was to send less: one payload at most every 8 milliseconds, 125 a second. That was chosen to protect a link that your own trace then proved was never under strain. The delay turned out to be a memory leak instead, which is now fixed, so that rate limit is doing nothing useful and is throwing away detail for a reason that no longer exists.

Two changes have gone in.

Unchanged payloads are no longer sent at all. Everything on this path is state: a trigger program, a lightbar colour, a rumble level. Sending one that is byte for byte identical to the last one cannot change anything on the controller, and at 19,600 packets a second those repeats were consuming the budget that genuine changes needed. Whether that alone fixes the skipping depends on how much of that flood is repeats, which nobody knows yet, so the trace now counts them.

The pacing floor is now per transport. On USB it drops from 8 milliseconds to 2, which is four times the resolution. Your trace measured writes at a tenth of a millisecond, so there is no cost to it. On Bluetooth it stays at 8, and that is deliberate rather than lazy: a DualSense Bluetooth link delivers on a fixed connection interval, so writing faster does not reach the pad sooner, it piles up below us. That pile is exactly the runaway this whole thread started with, and it is not worth recreating for a little smoothness.

So on USB you should hear a clear improvement in the skipping. On Bluetooth expect less, and if repeats turn out to be most of that traffic, expect an improvement there too.

If it is still noticeable, one more log from this build would settle the last of it, and this time two numbers do it. dup says how many of those packets were identical repeats, and bt says which floor the session was running under. If dup is most of the traffic then the remaining skipping is coming from somewhere other than this pacing. If it is not, then genuine changes really are arriving faster than the floor allows, and that is a case for lowering it further on USB with evidence behind the number instead of a guess.

Either way, thank you. This thread went from a symptom nobody here could reproduce to a measured defect and a fix, entirely because you ran the trace and posted the file.

[Jobima1st]

thank you, now the latency/delay is feel like 0 (feel like using without using PadForge)!

the skipping maybe get better, but it's still there

[Jobima1st]

I feel the last build is kinda odd, the skipping in BT is kinda same as PadForge_r3194@ee93187, but with usb is worst than even the BT in both

padforge-trace usb.log

padforge-trace bt.log

[hifihedgehog]

@Jobima1st, two logs, one for each transport, is exactly what was needed, and they show that the last change put a good idea in the wrong place. USB being worse was not odd at all once the numbers are read.

What the logs say

Here is USB in the middle of a burst:

enq=16886  wr=0  coal=16459  dup=427  depth=1  wmax=0.0

Writes of zero. For several seconds together, nothing was reaching the controller at all. That is why USB felt worse than Bluetooth: it was not delayed, it was silent.

Bluetooth in steady state, from your other log, is healthy by comparison at enq=122 wr=114. Same game, sane rate. So the bursts are the whole story, not the transport, and USB simply happened to be where you caught one.

One good piece of news in there: in both files the numbers add up exactly, every packet accounted for as written, superseded or repeated. The memory leak from the earlier build is genuinely gone.

What went wrong

A burst is roughly 16,000 packets a second that are byte-for-byte identical to what the controller already has, with the occasional real change buried in it.

The repeat check I added was on the wrong side. It ran when a packet was about to be sent, not when it arrived. So the sequence was: a real change lands in the slot, the flood of identical packets overwrites it microseconds later, the sender wakes two milliseconds after that, finds an identical packet, correctly recognises it as something the pad already has, and sends nothing. Every real change was destroyed before anything looked at it.

The trace states that plainly once you know what to look for. Duplicates counted exactly one per sample while writes counted zero. The only thing being examined was the spam, and every genuine change had already been thrown away.

What changed

The check now runs at the door. A packet identical to what the controller already holds is discarded the moment it arrives, so it never gets the chance to displace a pending change. What survives in the slot is exactly the changes, and the write rate becomes the rate at which things actually change rather than the rate the game happens to write at.

This should behave better on both transports, and USB should no longer be the worse of the two.

The pacing floors are unchanged: 2 ms on USB, 8 ms on Bluetooth. They now act as a ceiling on genuine changes rather than a sampling rate applied to a flood, which is what they should have been all along.

Four tests pin the rule, including the one that would have caught this class of mistake: nothing counts as a repeat before the first packet of a session, or a pad would sit holding whatever state it powered on with.

If you have the patience for one more round, a log from this build on USB is the one that settles it. What to look for is simple: wr should now be greater than zero through a burst, and roughly track the number of real changes rather than sitting at zero or tracking the sample rate.

Thanks for testing both transports separately and posting both files. Doing that is what made this diagnosable in one pass instead of several.

[hifihedgehog]

@Jobima1st, testing both transports on the same build is what made this readable, and the two results together identify the fault precisely. The last change was half a fix, and the other half was a regression I introduced.

The two numbers

USB, inside a burst:

enq=19076  wr=6  coal=84  dup=18986

Bluetooth, same build, steady:

enq=290  wr=118  coal=90  dup=84

Six writes a second against a hundred and eighteen. That gap is your entire report, including why one transport felt fine and the other did not.

Why the write rate matters more than I assumed

This lane is not the only thing writing to your controller. PadForge writes the same report to the same DualSense thirty times a second whenever it is mirroring something the game is driving, which while a game is running the triggers it always is.

So a repeated packet from the game is not redundant after all. It re-asserts the game's own payload over that other writer. By discarding repeats, I left the game's state being the most recent write only as often as the game changed it, six times a second inside a burst, against something writing thirty times a second. Your controller spent most of its time holding the other one.

On Bluetooth this lane was writing 118 times a second and comfortably won, which is exactly why you heard it on USB and not on Bluetooth. Your two logs are the same build behaving differently for a reason that is entirely about rate.

The belief behind the last change was simply wrong: "identical to what I last sent" does not mean "identical to what the controller currently holds".

What changed

A repeat is now dropped only while something is already waiting to go out.

That is all the first fix ever needed. If a real change is waiting, the flood cannot displace it, which was the bug that made a burst deliver nothing at all. If nothing is waiting, a repeat is kept and sent, so re-assertion continues at the normal pacing, 500 times a second on USB and 125 on Bluetooth.

USB should now be the better of the two rather than the worse, and Bluetooth should stay as it is.

On "after closing the game"

Your log settles this one, and the answer is that it is not this lane.

After the game closed, the trace holds at zero packets in and zero writes out for 157 seconds while the controller was still acting. That is the exact test the counters were added for. Nothing here was writing to your controller during that time.

What is left is the trigger state itself. Rumble does get released: the mirror expires 1.5 seconds after the game stops writing and PadForge's own zero goes out on the next pass. An adaptive trigger does not, because nothing takes authorship of it unless you have set a trigger mode on the slot, and the controller simply holds the last program the game gave it.

That behaviour is deliberate rather than overlooked. Reclaiming trigger state that PadForge does not own was tried before and broke both the mic LED and adaptive triggers on real hardware, so it is not something to change casually on this thread. If you want the trigger released, setting any adaptive trigger mode on that slot makes PadForge the author and it takes the trigger back after the game exits.

Worth being precise about one thing: this got noticeable again because the lane started delivering. On the earlier builds it was writing nothing through those bursts, so there was no state left on the controller to get stuck.

If you have another round in you, a USB log from this build is the one that closes it, and one number does it: wr through a burst should now be in the hundreds rather than 6.

[Jobima1st]

I only test with usb for now, PadForge_r3196@a29583c has more odd problems, now "After closing the game" is back!

padforge-trace.log

[Jobima1st]

I feel the BT in PadForge_r3196@a29583c work now without skipping!

here padforge-trace.log

[Jobima1st]

the PadForge r3197@7b71380 still has latency/delay problem that keeps running after the game exits, the problem that back in PadForge_r3196@a29583c, which is the old problem that was already fixed before

padforge-trace.log

anyway, I dont need PadForge to emulated usb Dualsense using Dualsense via USB (for now at least), so the last build is fine for me now

[hifihedgehog]

@Jobima1st, this log is the one that closes the part this thread started on, and it also answers the part you say is still there. Different answers for each.

The lane is fixed

Your burst on this build:

enq=19583  wr=444  coal=75  dup=19064  depth=1  wmax=0.1

Compare it to the same burst on the previous build, which was 6 writes a second. It is now 444, right at the pacing floor, with one payload in hand at any moment and the slowest write measuring a tenth of a millisecond. That is the lane doing exactly what it should against a game writing 19,000 packets a second. Your polling held 1000 to 1001 Hz the whole session as well.

What is still happening after you exit, precisely

This is where I have to disagree with the description, and the log is what I am disagreeing from.

After the game closed, PadForge wrote nothing at all to your controller on this path for 56 seconds, until you closed the app. Not a slow trickle, not a backlog draining. Zero.

So whatever you are feeling afterwards is not delayed traffic arriving late. It is the controller holding the last thing it was given. Those are different problems with different fixes, which is why the distinction is worth making rather than being pedantic.

Your log even shows PadForge taking part of the controller back, and shows exactly when:

01:41:09.1  242 packets in, 242 written     <- game still running
01:41:10.6  30 packets, then silence        <- game exits
01:41:11.0  LIGHTBAR out ... ledBit=False   <- PadForge reclaims the light

1.4 seconds after the game's last packet, PadForge decides the game has let go and takes the lightbar back. It then re-asserts it every five seconds for the rest of the session. That is the mechanism working.

Why the trigger is not reclaimed with it

Because PadForge always authors the lightbar and only authors the triggers when you have asked it to.

If the slot has no adaptive trigger mode set, nothing in PadForge ever claims the trigger, so when the game stops writing there is simply no author left and the controller keeps the last program it was given. It is not stuck in the sense of something being wedged. Nobody has told it anything different.

So there is something you can do today: set any adaptive trigger mode on that slot. PadForge then becomes the trigger's author and takes it back after the game exits, exactly as it already does with the light in your log above.

Why it does not do that on its own

The only signal available is "the game has stopped writing", and that is not the same question as "the game has gone away". A game can set a trigger effect once when a level loads and never write it again while you play for an hour. Releasing the trigger on a silence timer would take it away from that game mid-session.

That is not a hypothetical. Reclaiming state PadForge does not own was tried, and it cost the microphone LED and the adaptive triggers on real hardware. It was reverted for that reason.

The signal that would make it safe is the driver saying the game closed its handle on the virtual controller, which is a different question from silence and does not exist yet. That is a change on the driver side, and it is the honest answer for why this is not simply switched on.

Where that leaves the thread

Everything reported here that belonged to this lane is fixed and your own traces are what fixed each one: the leak, the eviction, and the write rate. Glad the build works for you.

If you do come back to the USB DualSense persona later and something feels wrong, the trace is still the fastest route and you know how to take it now.

[Jobima1st]

My explanation might not be clear in the last comments, so I'll summarize: I didnt see Bluetooth problems in the last two builds; the issues were when use it with the USB

Also, Something is on my mind: are some of the comments automated by artificial intelligence?

[hifihedgehog]

@Jobima1st, that lines up with the traces, so nothing was lost in translation.

Bluetooth was healthy in both of those builds. Your Bluetooth log showed 118 writes a second, comfortably ahead of everything competing with it, which is why you never heard the problem on that side. USB was the one that broke, and it broke twice for two different reasons: first the change ate every real update during a burst, then it stopped re-sending state often enough to hold the controller. Both were USB-only symptoms of rate.

The latest build puts USB at 444 writes a second through the same burst that used to get 6, so the two transports should behave alike now.

Thanks for the run of testing on this. Three separate faults on this path came out of your traces: a memory leak that had been there since the lane was written, then each of the two mistakes made while fixing it. None of the three were reachable by reasoning about the code, and every one of them was caught by a log you took.

[hifihedgehog]

@Jobima1st @Trihy, the last piece of this is fixed. You both reported it independently: @Jobima1st that the controller keeps acting after closing the game, @Trihy that you can hear the trigger click after the game is gone. Same thing, and it is now handled rather than explained.

What it actually was

A DualSense stores its adaptive trigger program in the controller itself, and keeps it until something sends a different one. There is no timeout in the hardware. So a game that exits while a trigger effect is loaded leaves that effect sitting there, and PadForge is the only thing left that could clear it.

@Jobima1st's last trace is what proved this was not the forwarding misbehaving. After the game closed, PadForge wrote nothing at all to the controller for 56 seconds. Nothing was late, nothing was still draining. The controller was simply holding what the game left.

Why it was not already handled

I said earlier in this thread that fixing this properly needed a change in the driver, so PadForge could be told when a game lets go of the virtual controller.

That was wrong, and it is worth correcting plainly because it would have parked this indefinitely.

No virtual controller driver offers that signal. ViGEmBus does not, and neither does VIIPER. And tools that do this job do not wait for one. DualSenseY-v2 drives a physical DualSense from a game's trigger and haptic instructions, which is the same problem exactly, and it uses a plain staleness window: fifteen seconds without an update and the driving app is treated as gone.

That is what PadForge now does, using the same fifteen seconds rather than a number I picked.

Why fifteen and not one

This is the part that matters, and it is why the fix had to be careful rather than quick.

A game can set a trigger effect once when a level loads and then never mention it again while you play. Release too eagerly and you take the trigger away from a game that is still running and still wants it. That is not a theoretical worry. PadForge tried reclaiming state on a 1.5 second window once before, and it cost the microphone LED and the adaptive triggers on real hardware.

Fifteen seconds is far clear of that, and the release is a single frame rather than something asserted continuously, so if a game does come back it simply wins the next write and nothing fights it.

What the release actually touches

Only the two trigger blocks, and nothing else in the report.

The lightbar, the player lights, the microphone LED and the whole audio side are PadForge's own to manage, and it is already writing them thirty times a second. A release that grabbed at those as well would end up fighting itself. Rumble needed nothing: it is already released about a second and a half after a game stops, which you can actually see happening in @Jobima1st's trace as PadForge takes the lightbar back 1.4 seconds after the last packet from the game.

Trying it

Latest dev build. Close a game that was driving the triggers, wait about fifteen seconds, and the trigger should let go on its own. No settings change needed, and you no longer have to set a trigger mode on the slot to get it back, which was the workaround offered before this was fixed properly.

@Jobima1st, this came out of your traces again. Four faults on this path have now been found and fixed from logs you took.

[Trihy]

I can confirm everything works as expected on build from a few minutes ago. At least using real wireless dualsense and virtual dualsense (ps5) full.

No trigger actuator after game close. No ghost triggers and crazy led bar after finishing a race in F1 22

Tested ratchet and F1 22.

[hifihedgehog]

Everything reported in this thread is now fixed and confirmed on hardware. @Trihy's test a few minutes ago was the last one outstanding, and it came back clean on both games he checked.

What was actually wrong

Six separate faults, only the first of which was the one this thread opened on. The other five were found underneath it, and two of those were mistakes made along the way.

The audio session. Speaker and advanced haptics each ran their own packet counter into the single audio session the controller tracks. With one stream live the counter was monotonic and everything worked, which is exactly why speaker-only and haptics-only were both fine. With both live, that one session saw a counter jumping backwards, and the controller did what any device does with a discontinuous stream: went quiet, then resynced onto whichever stream kept talking. That is @vlue-c's one-second gap and the recovery into only one feature, and it is also why @Trihy's speaker went silent the moment he reached gameplay.

A leaked buffer per dropped packet. The effect forwarding used a bounded queue set to discard when full, on a belief written into a comment: that a refused write reports itself as refused, so the memory reserved for that packet could be released. It does not. It accepts the write, reports success, and discards the item, so every dropped packet leaked its reservation. @Jobima1st's first trace measured the cost at roughly 10,500 leaked allocations per second, which is what his growing delay actually was.

A rate limit set for a reason that turned out to be false. While the delay was being blamed on a saturated Bluetooth link, the forwarding was capped at one packet every 8 milliseconds. His trace then measured writes at a tenth of a millisecond and killed that explanation outright. The cap stayed anyway and became the skipping.

Repeats filtered on the wrong side. Fixing that introduced a worse bug: real updates were being destroyed by the flood of identical packets before anything looked at them. His USB trace showed writes of zero for seconds at a time.

Repeats suppressed outright. Fixing that introduced the opposite bug. PadForge writes to the same controller thirty times a second while mirroring what a game drives, so a repeated packet is not redundant, it re-asserts the game's own state over that. Suppressing repeats left the game winning six times a second against a writer running at thirty.

Nothing handing the triggers back. A DualSense holds its adaptive trigger program in firmware until something loads a different one. A game that exits mid-effect leaves it there. That is the "keeps running after closing the game" both @Jobima1st and @Trihy reported, and the trigger click @Trihy could hear after exit. It now releases after fifteen seconds of silence from the game, a number taken from DualSenseY-v2, which solves the same problem the same way.

The commits

Commit	What it did
81140f17	Speaker and haptics share one audio session. The original bug.
b1d0906a	A heartbeat that says why the Bluetooth audio lane is quiet.
aac1bc86	A heartbeat for the ghost-trigger reports, which is what made everything after this measurable instead of guessed.
c07c0d92	Forward the newest state at a bounded rate.
ee93187f	The leaked buffer per dropped packet. This is the one that fixed the delay.
59c5ae86	Skip unchanged state, pace by transport. Correct in intent, wrong in placement.
a29583c1	Filter repeats at the door rather than at the sampler. Fixed one half, broke the other.
7b71380e	A repeat yields to a pending payload and nothing more. The rule that holds.
e01d721f	Hand the triggers back when the game goes away.

Two of those made things worse before they got better, and they are listed rather than quietly folded into the ones that worked.

Answered rather than fixed

@Trihy's HidHide question. PadForge owning its hide states at launch is by design rather than a reset, and the reasoning is earlier in this thread.

@vlue-c's mute button. PadForge forwards that button and mirrors the host's mute rather than inventing one, so a game that acts on the first press without implementing the toggle back produces exactly what was seen. That is outside PadForge, and the practical route is binding it to whatever mute hotkey your chat or recording application exposes.

The people who did this

@vlue-c opened it with a diagnosis that was already correct, updated PersonaVerify into a reproduction tool that separated the sequential case from the simultaneous one, pointed at the right direction for the fix, and then confirmed it on a DualSense Edge over Bluetooth and tested the microphone alongside it.

@Jobima1st ran trace after trace across build after build, on both USB and Bluetooth, including the two where the fix made his controller worse than before he started. Four of the six faults above were found in his logs and none of them were reachable by reading the code.

@Trihy reported the speaker dropping out in gameplay, which turned out to be the same bug seen from the other side, spotted the ghost trigger and the lightbar behaviour in F1 22 that would otherwise have been left behind when this thread closed, and confirmed the final build on hardware.

Five games between the three of you: Arknights Endfield, Ratchet and Clank, F1 22, GTA V Enhanced and Indiana Jones and the Great Circle. Two controllers, both transports.

[Jobima1st]

the new build with the usb is still has latency/delay problem that keeps running after the game exits, the problem that back in PadForge_r3196@a29583c, which is the old problem that was already fixed before

and now the LEDs seems not working in BT, so I think I will keep using old PadForge_r3196@a29583c (or PadForger3197@7b71380) for now

[hifihedgehog]

@Jobima1st, no log, nothing to act on.

Five of the six faults fixed here were found in your traces. None were findable from a description, including the two you are describing now. You know this, because you watched it happen five times.

The builds you are going back to are the broken ones. r3196@a29583c is where your own USB trace read 6 writes a second through a burst. r3197@7b71380 has no trigger release at all, which is the after-exit behavior you are reporting. Going back to those does not avoid what you are describing, it guarantees it.

The trigger release waits fifteen seconds of game silence before it fires. Deliberate, explained when it shipped, and the same number DualSenseY-v2 uses. Check immediately after closing and it is still held. @Trihy confirmed it on hardware across two games.

LEDs are new and nothing here touches them. The release frame claims two fields, the left and right trigger blocks, and sets no LED bit at all. It cannot change a lightbar, player lights or mic LED. Which LED, when, which build.

You reported a problem, you were asked for traces, and every one you posted got a diagnosis and a build the same day. Six faults, three days. Reporting two more without a log and announcing you are reverting to a build this thread measured as worse is not a contribution, it is walking away mid-diagnosis and leaving the work half done.

If these are real on the current build, you are the only one seeing them, and a trace is the only thing that finds them. Post one and it gets finished. That is the deal, and it has not changed.

[Jobima1st]

ok here usb log
padforge-trace.log

it has same problems as #300 (comment) and it's not only advanced haptics and adaptive triggers delayed but also the LEDs feeds (and as Trihy said sometimes it has crazy led bar)

I will post BT log next time

[Jobima1st]

bt one padforge-trace.log
seems work fine as old PadForge_r3196@a29583c (or PadForger 3197@7b71380)

the LEDs work this time (maybe it was some random bug/glitch in the game itself, which is GTA V E)

[Jobima1st]

in short, the BT seems fine (or even perfect) now (since PadForge r3196@a29583c), the USB is not

[hifihedgehog]

@Jobima1st, thank you for going back and getting both. That was the right call and it paid off immediately: one of the two things you reported is real, it is now identified, and it was in the logs.

For context on the pushing: we are on vacation this week, which is why users are carrying more of the testing than usual. Your traces have been doing a disproportionate amount of the work in this thread and it is appreciated.

We also have a DualSense on the bench here and have been running the same tests, which is how the LED one got confirmed on a second machine within the hour.

The LED one is real

From your USB log:

LIGHTBAR out vf1=0x80 ledBit=False rgb=48,255,255

ledBit=False means PadForge is sending the packet but deliberately not claiming the light bar.

Once a game writes the bar, PadForge stands down and lets the game own it, so the game's colour is not fought over. That part is intentional. What is missing is the other half: when the game exits, nothing hands the bar back. The claim never lapses, so the bar sits on whatever the game last set for the rest of the session, and a restart is the only way out.

That is your "LED feeds" complaint, and we reproduced it here on our own pad with a different game. So your instinct that it was a game-side glitch was generous but wrong, it is ours. A fix is written and going out.

One correction on the quote, because two different things are being run together. @Trihy reported a crazy light bar in F1 22, flickering and fighting, and he retested after the last build and confirmed that one fixed:

No trigger actuator after game close. No ghost triggers and crazy led bar after finishing a race in F1 22

That was the two writers racing each other, and it went with the write-rate fix. What you are seeing is the opposite symptom: the bar is not flickering, it is frozen on the game's colour and never handed back. Same subsystem, different fault, and only the second one is still open.

The delay is still not this lane

Your two logs disagree with the feel, and the numbers are worth seeing:

USB  enq=19838  wr=439  coal=98   dup=19301  depth=1  wmax=0.1
BT   enq=19854  wr=64   coal=617  dup=19173  depth=1  wmax=0.2

The transport you say is worse is writing seven times more often than the one you say is fine. USB is running at its pacing limit with one packet in hand and writes costing a tenth of a millisecond. There is no backlog in it.

After the game closed, your USB log holds zero writes for 94 seconds. Nothing was being sent to the controller at all during the period you describe as delayed.

The trigger release also fired correctly, twice, at exactly fifteen seconds each time.

So whatever you are feeling on USB, it is not this path, and it is not a queue. Once the light bar fix lands it is worth retesting, because a bar stuck on a game's colour and effects that feel wrong afterwards may well have been the same thing all along.

One number we want to look at

Bluetooth is writing 64 times a second where its own pacing floor allows 125. That is not something you reported and it may be nothing, but it is the one figure in either log that is not where it should be, and it came out of your traces too.

[Jobima1st]

Unfortunately, the situation remains the same with the new build and usb

this time I closed padforge as soon as I close the game (maybe it was why you didnt see the problem because I was wait until the controller stop the feedbacking then I close padforge) padforge-trace usb.log

I will test BT in the next comment

[Jobima1st]

bt is still fine, but here the log anyway
padforge-trace bt.log

[hifihedgehog]

@Jobima1st, you solved it, and it was the aside in brackets:

maybe it was why you didnt see the problem because I was wait until the controller stop the feedbacking then I close padforge

That is exactly why. Fixed, and it is in the current dev build.

What was happening

The trigger release waits fifteen seconds of silence from the game before it fires. Closing PadForge is the one case where those fifteen seconds never arrive.

You close the app within seconds of the game. So the release never got to run, and whatever the game left loaded stayed loaded, because the only thing that would have cleared it had just exited. Nothing was wrong with the release itself. It simply was not there any more when the moment came.

That is also why we could not reproduce it here. The same test on the same build passed on our own pad, because whoever ran it waited for the controller to settle before quitting. Same code, opposite result, decided entirely by how long you wait before closing PadForge. You were the only one doing the thing that exposes it.

The fix

PadForge now hands the triggers back as part of shutting down, before it tears anything else down. Close the game and close PadForge immediately, which is what you have been doing all along, and the pad is released on the way out.

It only fires if that lane actually drove your pad during the session, so nothing is written on exit if nothing was forwarded.

Retesting

Do exactly what you did in the last log, including closing PadForge straight after the game. That was the correct test, it just happened to be the one nobody else was running.

If it is still held afterwards, the trace will say so directly. Look for:

DS5EFFECT slot=0 RELEASE triggers (shutdown)

That line is new and it means the release went out as PadForge closed.

Your read that Bluetooth is fine and USB was the problem matches the logs, and this was on the USB side. The light bar fix from earlier today is in the same build.

[Jobima1st]

Unfortunately, in r3212@fd8b007 nothing seems fixed with the usb

padforge-trace usb.log

BT will be in next comment

[Jobima1st]

bt seems fine
padforge-trace bt.log

[hifihedgehog]

@Jobima1st, your log answers this one, and it rules out the thing we were both looking at.

Both trigger releases fired, correctly:

17:30:34  RELEASE triggers (source idle 15000ms)
17:34:32  RELEASE triggers (shutdown)

The second is the new one. It went out as PadForge closed, which is exactly what it was added to do. So the triggers are being handed back and are not what you are still feeling.

What the same log shows instead

17:34:29  LIGHTBAR out vf1=0x80 ledBit=False rgb=48,255,255

That is the last light bar line before the app closes, ten seconds after the game exited. ledBit clear, and the colour is still GTA V's cyan. The bar was never handed back.

The reclaim for that shipped earlier today, but it needs fifteen seconds of quiet before it re-arms, and you close PadForge about ten seconds after the game. So it is the same gap the trigger had, one subsystem over: the reclaim is correct, it simply is not there any more when the moment comes.

Fixed the same way. The frame PadForge sends on the way out now carries the slot's colour as well as the trigger release.

Retest

Same as before, closing PadForge right after the game. The line to look for changed:

DS5EFFECT slot=0 RELEASE triggers+lightbar (shutdown)

One thing worth being precise about

"Nothing seems fixed" and the trace disagree, and the disagreement is useful rather than annoying. Two separate faults have now been fixed from these logs, and both were invisible from the description because "the controller keeps doing things after I close" covers a stuck trigger, a stuck light bar, stuck rumble and stuck haptics equally well.

So if something is still wrong after this build, the single most useful thing you can add is which of those it is. Is the bar the wrong colour, are the triggers stiff, is it vibrating, or is it the haptics. That one word narrows it faster than another log will, and the log is already telling us the triggers are clean.

[Jobima1st]

"Nothing seems fixed" and the trace disagree, and the disagreement is useful rather than annoying. Two separate faults have now been fixed from these logs, and both were invisible from the description because "the controller keeps doing things after I close" covers a stuck trigger, a stuck light bar, stuck rumble and stuck haptics equally well.

So if something is still wrong after this build, the single most useful thing you can add is which of those it is. Is the bar the wrong colour, are the triggers stiff, is it vibrating, or is it the haptics. That one word narrows it faster than another log will, and the log is already telling us the triggers are clean.

in r3212@fd8b007 usb, the long delay that keep getting bigger is not fixed in all feeds, the crazy led bar is still there (Or how else to describe it? (I am not native English speaker) I feel like there's an overlap between two, one lagging and the other not lagging, and the controller is flashing between them.)

[Jobima1st]

Unfortunately, even in r3213@1bda40c the usb delay (and the led flashing) is not fixed

padforge-trace usb.log

[Jobima1st]

bt is good as before padforge-trace bt.log

[hifihedgehog]

@Jobima1st, your English was not the problem. That sentence was the most precise thing anyone has written in this thread:

I feel like there's an overlap between two, one lagging and the other not lagging, and the controller is flashing between them.

That is exactly what was happening, and it is fixed.

Two writers, one light bar

There were two things writing your light bar at the same time.

The pass-through forwards the game's own bytes to your controller, on USB up to 500 times a second. Separately, PadForge keeps its own copy of what the game last set and re-sends that copy 30 times a second. That copy is always a fraction behind, because it is a copy.

So the controller was being told two different colours in turn: the live one, then the slightly older one, then the live one again. One lagging, one not, flashing between them. Your description was not vague, it was the mechanism.

Your trace has the count. In the last USB log, 135 light bar writes with PadForge claiming the bar against 6 without, all of them carrying the game's colour, while the effect lane was writing 439 times a second.

Why USB and not Bluetooth

You have said all along that Bluetooth is fine and USB is not, and this explains it.

On USB the pass-through runs at up to 500 writes a second against that 30 a second copy, so the two collide constantly. On Bluetooth the same lane is capped at 125 and merges far more aggressively, so they collide much less. Same fault, different visibility, which is why every Bluetooth log you sent looked clean.

The fix

While a game is driving the bar, PadForge no longer touches it at all. The game's own bytes go straight through and nothing competes with them.

This was already solved once for the rumble motors, years-old code that says in its own comment that it zeroes them so it does not race the pass-through on the same controller. The light bar had the identical problem and never got the identical fix.

Nothing changes when no game is driving the bar. PadForge still owns it then, which is what puts your player colour back.

Retest

Same USB test. What should be gone is the flashing and the sense of two things overlapping.

If some feed still lags, the same question as before is the fast one: which feed. Light bar, triggers, vibration, or haptics. The light bar is the one just fixed, so if it is one of the others we are looking at a different writer again.

[Jobima1st]

which feed. Light bar, triggers, vibration, or haptics.

in r3213@1bda40c it was all those

[Jobima1st]

in r3214@c6b4591 things changes indeed, it still has long delay that keep getting bigger in the feeds but seems they will not keeps running after the game exits, also the flashing is fixed or it's way better at least

padforge-trace usb.log

[Jobima1st]

bt is fine again padforge-trace bt.log

[hifihedgehog]

@Jobima1st, good, that narrows it to one thing. Flashing gone and nothing running on after the game leaves the growing delay, and the answer to that was in what you have been saying since the beginning.

Bluetooth was the clue the whole time

You have said Bluetooth is fine, or perfect, in every single report. USB gets worse the longer you play. Same code, same controller, same game.

The difference between them is how fast PadForge writes:

USB  440 writes per second
BT   125 writes per second

Writing faster does not make anything arrive sooner. Past the rate the controller can take them in, the extra writes pile up below PadForge, in the part of Windows that talks to the USB device. That pile only grows while you play, and it is not something this program can see or measure. A delay that keeps getting bigger is exactly what an unbounded queue feels like.

Everything PadForge can measure was clean in your log the whole time it was happening. One packet in hand, writes costing a tenth of a millisecond, polling steady at 1000 Hz. That is why the traces kept looking healthy while you kept being right.

Why I got this wrong for four builds

I checked this early on and dismissed it, using the wrong number. The trace reports the slowest single write each second, and it stayed tiny, so I concluded the link was not saturated.

That number measures how long the call takes, not how long the data takes to arrive. A buffered write returns the instant Windows accepts it. It cannot see a queue forming underneath. It was never evidence of anything except that our own call is cheap, and I treated it as proof.

The fix

USB now writes at 125 times a second, the same as Bluetooth.

The rate is not a guess this time. DualSenseY-v2, which drives adaptive triggers, haptics and the light bar on a real DualSense, runs its whole output loop at 10 milliseconds, 100 writes a second. It is the same project the fifteen second release timing came from. 125 is inside that, and it is the rate you have been calling perfect on the other transport all day.

The 2 millisecond setting was mine, chosen while I still believed writes were free. It is the same wrong inference twice, and it survived four builds because the delay it caused looked exactly like the delay it was meant to fix.

Retest

USB, same as always. What should be gone is the delay growing the longer you play.

If any skipping comes back with it, say so plainly and it will be traded off against a measurement rather than a hunch, because now there is one: Bluetooth has run at this exact rate for you all day.

[Jobima1st]

you nail it this time in r3215@775559d

thank you so much, the usb is work fine (as using usb without PadForge if I am not mistaken), bt is fine too, I think the log is not needed :)

[hifihedgehog]

@Jobima1st, that is the result, and thank you. Genuinely.

Look at what your testing actually produced. Every one of these was found in a log you took, and not one of them was findable any other way:

1. A memory leak in the effect forwarding, roughly 10,500 discarded allocations a second, sitting there since the lane was written.
2. Real updates being destroyed during a burst, writes dropping to zero for seconds at a time.
3. The write rate collapsing to 6 a second on USB while Bluetooth held 118, which is why one transport felt broken and the other did not.
4. Nothing releasing the controller when PadForge closed, which you found yourself, in brackets, almost as an afterthought.
5. Two things fighting over the light bar, which you described so precisely that the sentence was the diagnosis.
6. Writing to the controller four times faster than it could take it, the growing delay, and the one you were right about from the very first message.

Six faults in about three days, on a path that had been shipping quietly for months.

Two of those deserve saying out loud, because they were not testing, they were diagnosis.

The one in brackets. You wrote that you close PadForge as soon as you close the game, and wondered aloud whether that was why we could not reproduce it. That was exactly why. We were waiting for the controller to settle before quitting, and that wait was hiding the entire bug.

And "an overlap between two, one lagging and the other not lagging, and the controller is flashing between them." You apologised for your English right before writing the clearest description of a race condition anyone has put in this tracker. It was two writers on one light bar, one live and one a frame behind, and that sentence is what found it.

You were also right about USB and Bluetooth from the first message and stayed right through six builds, including several where our own traces looked perfectly healthy and we told you so. Continuing to push back when the numbers disagreed with you is what got this to the end.

Thank you for the patience, especially through the two builds that made things worse before they got better. That is the part most people quite reasonably do not stick around for.

[hifihedgehog]

Everything reported in this thread is fixed, and every fix has been confirmed on hardware by the person who reported it.

@Jobima1st on the final build: "the usb is work fine (as using usb without PadForge if I am not mistaken), bt is fine too." @Trihy confirmed the trigger and light bar behaviour on Ratchet and Clank and F1 22. @vlue-c confirmed the original fault on a DualSense Edge over Bluetooth, with the microphone tested alongside it.

What was actually wrong

Nine faults. One was the bug this thread opened on. The rest were found underneath it, and two were mistakes made while fixing the others.

Speaker and haptics could not start together. Both carry the packet 0x11 audio session header and the controller tracks one session, but PadForge ran a separate counter for each stream. With one stream live the counter was monotonic and everything worked, which is why speaker-only and haptics-only were both fine. With both live the session saw a counter jumping backwards and the pad went quiet, then resynced onto whichever stream kept talking. @vlue-c's one-second gap, and also why @Trihy's speaker died the moment he reached gameplay.

A leaked allocation per dropped packet. The forwarding used a bounded queue set to discard when full, on a belief written into a comment: that a refused write reports itself as refused. It does not. Every Drop mode accepts the write, reports success, and discards the item. Measured in @Jobima1st's first trace at roughly 10,500 leaked allocations a second.

A rate limit set for a reason that turned out to be false. The delay was blamed on a saturated Bluetooth link, so the forwarding was capped. The same trace then measured writes at a tenth of a millisecond and killed that explanation. The cap stayed and became audible skipping.

Repeats filtered on the wrong side, which destroyed every real update inside a burst. Writes read zero for seconds at a time.

Then repeats suppressed outright, which broke it the opposite way, because this lane is not the pad's only writer.

Nothing released the adaptive triggers when a game exited. A DualSense holds its trigger program in firmware until something loads a different one.

Nothing released them when PadForge itself exited either, which is the case @Jobima1st was actually hitting and which he identified himself.

The light bar was never handed back once a game claimed it, for the rest of the session.

Two writers fought over the light bar while a game was driving it, one live and one a frame behind. @Jobima1st's description was the diagnosis: "an overlap between two, one lagging and the other not lagging, and the controller is flashing between them."

PadForge wrote to the pad over USB four times faster than it could take them in, so the excess queued below the application and grew for as long as you played. The rate is now the one DualSenseY-v2 uses to drive a real DualSense, and the one that has worked over Bluetooth throughout.

The commits

Commit	What it did
81140f17	Speaker and haptics share one audio session. The original bug.
b1d0906a	A heartbeat that says why the Bluetooth audio lane is quiet.
aac1bc86	A heartbeat for the ghost-trigger reports. Everything after this was measured rather than guessed.
c07c0d92	Forward the newest state at a bounded rate.
ee93187f	The leaked allocation per dropped packet. This fixed the growing delay.
59c5ae86	Skip unchanged state, pace by transport. Right idea, wrong placement.
a29583c1	Filter repeats at the door. Fixed one half, broke the other.
7b71380e	A repeat yields to a pending payload and nothing more. The rule that holds.
e01d721f	Release the triggers fifteen seconds after a game stops writing.
fbed323b	Hand the light bar and player pips back when the claimant leaves.
22463a5e	Release the triggers when PadForge itself exits.
1bda40cd	Hand the light bar back on shutdown too.
c6b45919	Stop fighting the pass-through for the light bar.
775559d5	Write to USB at 125 Hz, the rate the reference uses.

Two of those made things worse before they got better. They are listed rather than quietly folded into the ones that worked.

Answered rather than fixed

@Trihy's HidHide question. PadForge owning its hide states at launch is by design rather than a reset.

@vlue-c's mute button. PadForge forwards the button and mirrors the host's mute rather than inventing one, so a game that acts on the first press without implementing the toggle back produces exactly what was seen. That is outside PadForge, and binding the button to a chat or recording application's own mute hotkey is the practical route.

@Trihy's F1 22 ghost trigger and erratic light bar, which he set aside for a separate thread that was never created. He retested it after the fixes above and reported it clean, so it closes here rather than being lost.

The people who did this

@vlue-c opened it with a diagnosis that was already correct, updated PersonaVerify into a reproduction tool that separated the sequential case from the simultaneous one, pointed at the right shape for the fix, then confirmed it on a DualSense Edge over Bluetooth and tested the microphone at the same time.

@Jobima1st ran trace after trace across seven builds, on both transports, including two that made his controller worse than before he started. Six of the nine faults were found in his logs and none were reachable by reading the code. Twice he did not just test but diagnosed: the note that he closes PadForge immediately after the game was the whole of one bug, and his description of the light bar was the whole of another. He was also right about USB and Bluetooth from his first message and stayed right through six builds in which our own instrumentation looked perfectly healthy.

@Trihy reported the speaker dropping out in gameplay, which turned out to be the same bug seen from the other side, caught the F1 22 behaviour that would otherwise have been dropped, and confirmed on hardware nobody here has.

Five games between the three of you: Arknights Endfield, Ratchet and Clank, F1 22, GTA V Enhanced and Indiana Jones and the Great Circle. Two controllers, both transports.

Evidence Status

Confirmed. Every fix above verified on hardware by the reporter, on the shipped build. The counters behind each diagnosis are quoted from the attached traces. Full suite green at 3,423 on the final build.

Hypothesized. That the USB rate is now optimal rather than merely correct. 125 Hz is the reference implementation's cadence and the rate that works on both transports here, but no one has swept the range to find where it starts costing detail.

Unverified. DualSense Edge on the final build. @vlue-c confirmed the original session fix on an Edge, but the six later fixes have only been confirmed on standard DualSenses.

Closing and locking. If anything resurfaces, open a fresh discussion and link back here.