Two questions from a Windows TrueForce stream implementation: idle whine at 0% force + session teardown semantics

[WnDTech]

Context

Hi! I'm a Windows dev building FFB tuning software that drives the RS50 / G PRO directly via the interface-2 stream (no Logitech SDK, no G HUB requirement) plus HID++ for settings. Your protocol docs (TRUEFORCE_PROTOCOL.md, PROTOCOL_SPECIFICATION.md) validated our implementation byte-for-byte — the 68-packet two-pass init, the type-0x01 pure-KF packet layout (bytes 6-9 cur, byte 10 = 0), the type-0x0e range patch (we replay the G HUB init with packet 50 rewritten to the wheel's own rotation, exactly your "90° on game launch" root cause), and the HID++ feature indices/SET fns (0x8138 fn2, 0x8137 fn2, 0x8139 fn3, 0x8133 fn1, 0x12 responses). Thank you for the reverse-engineering work — it's excellent.

Two questions from field experience on real RS50 hardware:

1. Idle whine at 0% force

With the stream active and 0% force commanded, users report an audible "bee"/dither from the TrueForce amplifier (one user described it as the motor vibrating/crunching; TF4ALL's README notes the same "wheel whines" when a TrueForce channel is held live). Your native libtrueforce runs a continuous 250 Hz stream — do you observe this whine at zero force on your hardware? Any mitigation beyond stopping the stream entirely?

Our current approach:

• The session stays in standby (connected, no init, no packets) until the app actually outputs force — so an idle app leaves the wheel completely untouched.
• At zero force while running, we write neutral once and then a keepalive every 250 ms (4 Hz), relying on the set-and-hold behavior and your documented ~1-minute session idle-revert.

Does a ~4 Hz keepalive cadence safely hold the session without stressing the amplifier, or is there a lower bound on the stream rate you'd recommend?

2. Session teardown semantics

We end a session by replaying init packets 67 (type 0x04 "stop/clear") + 68 (type 0x03 "start/play") followed by silence, which empirically releases the wheel back to its normal FFB path (game FFB works immediately after app close). Is the 67+68 replay the correct end-of-session handshake, or would a bare type-0x04 suffice? Understanding the exact teardown semantics matters for us because an abrupt close without it leaves the wheel in a stale session state that overrides all force paths until power-cycle (confirmed by your docs' set-and-hold + idle-revert behavior).

[Mhytee]

Hi, I am the TF4ALL dev.

What I suspect is happening is that the game you're experiencing this with natively supports Trueforce and the native API is still active. I have only been able to solve this in games which fully allow disabling Trueforce rather than just setting it to 0 volume.

[mescon]

Dug through the Windows captures, and then spent this week's hardware sessions on exactly your two questions. Long answer, because we learned a lot that changes the picture.

1. Idle whine

Confirmed on our hardware, and the root cause is simply a started stream engine: the whine is the cost of holding one open, at any rate. Logitech's answer is to never do it. With no game running, G HUB does not touch interface 2 at all (six idle captures, zero ep3 packets; every desktop setting rides HID++). In game menus the SDK keeps the session but streams keepalives with byte10=0, cur=0x8000 and a zeroed tail, never "4 new zero samples": a drained ring replayed as fresh audio is audible, true zeros in the keepalive form are not.

Your standby approach (connected, no init, no packets until real output) is exactly what G HUB does, so keep it. Two hardware results that should simplify your zero-force path:

• You do not need the 4 Hz keepalive at all. We left an armed engine in total host silence for 2.5 minutes and the first force packet after it applied instantly, no re-init, no perceptible ramp. The documented one-minute idle-revert applies to the session's range override (a 0x0e push reverts and the wheel broadcasts the restored range over HID++), not to the engine arming.
• Stopping and resuming is free: our driver now silences its stream 500 ms after the last activity and re-opens on demand, and on the bench the onset of the first force after silence was too fast to perceive. So the cleanest whine fix is full silence at zero force, resume when force returns.

2. Teardown

The 67+68 replay (0x04 stop/clear then 0x03 re-arm, 2 ms apart, then silence) is the correct handshake: every clean Windows session ends with exactly that pair, and we have never captured a bare 0x04 alone, so we treat the pair as the contract and cannot vouch for the half form.

The part worth engineering for: send the pair on your crash paths too. This week we confirmed on hardware that a session which dies without its teardown reaching the wheel leaves the engine in a state where the next session opens successfully (SetForceMode returns ok) and then never streams, in both directions, and even replaying the full init did not revive it; only a power cycle did. Our launcher now sends the pair from a supervisor process on abnormal exit for exactly this reason. One mitigating datum: a producer that dies mid-waveform does not leave standing torque, the firmware releases to centre quickly on starvation, but the armed-engine latch remains.

Since you drive the wheel directly, two more of this week's findings will matter to you sooner or later: texture samples only render when byte10's count is paired with 0x0d at byte 11 (0x04/0x00 is silently discarded), and a 0x0e range push only takes effect between START and STOP, the init sequence's own pushes are no-ops. Both are in the updated TRUEFORCE_PROTOCOL.md, and the 0x807A rev-light protocol (bare fn2+fn6, no arming) is in PROTOCOL_SPECIFICATION.md. Captures from your side are always welcome.

[WnDTech]

@mescon thanks — genuinely useful reply, and the crash-latch finding is the one that matters most on Windows, where processes die hard.

What we're taking from this:

1. Zero-force keepalive: dropping it. Our idle path currently writes neutral once, then a 4 Hz keepalive. Per your data we'll move to full host silence at zero force (stop pumping after a short quiet period) and resume on demand — same shape as your 500 ms silence. The standby lazy-engage (connected, no init, no packets until real output) stays as-is, since you confirmed it mirrors G Hub.

2. Teardown contract: 67+68 confirmed on our side too. We already replay the pair (0x04 stop/clear then 0x03 re-arm, then silence) and never send a bare 0x04, so we're aligned there.

3. Crash-path teardown: agreed, and a real gap for us. Our app has had native AV crashes in the field (since pinned and fixed, but the class exists), and a crash while the session is engaged would leave exactly the latched-engine state you describe — next session opens fine and never streams, power cycle required. We'll wire the pair into our crash path (best-effort write in the process-wide native exception filter before WER terminates, plus a supervisor-side retry if we add a launcher process). A power-cycle-only recovery is not acceptable for users who don't know the wheel has one.

4. Noted for future work: byte 10 paired with 0x0d at byte 11 for texture rendering (we're force-only, so unaffected), and the 0x0e range push only taking effect between START and STOP — the latter is worth us re-validating against our init-time range patch, given the init sequence's own pushes being no-ops.

@Mhytee on the native-API theory: not our case — we never use the SDK, and the whine reproduces with only our own stream active at 0% force, and disappears entirely in standby with zero packets. The stream engine itself is the source, which matches mescon's captures.

And per your standing offer: our diag packs already ship raw HID++ + TrueForce TX logs — when our tester next runs the OLED build we'll post the 0x8130 fn1 descriptor readback and frame TX/RX, completing the issue #20 offer.

[mescon]

On the whine: since your last message we root-caused a fixed buzz here, and the discriminator may save you time.

Ours sat at exactly 500.00 Hz with a strong third harmonic and almost no second, the odd-harmonic signature of a level stepping at a fixed rate rather than a resonance. Cause: two writers on an endpoint that carries one packet per millisecond, so the torque target alternated between their values every 1 ms.

Worth reconstructing the delivered samples from your own TX log and looking at the spectrum. An odd-harmonic tone at a frequency tied to your packet rate points at pacing; a clean tone with even harmonics is a different class and you can stop looking there. Measurements in docs/TRUEFORCE_PROTOCOL.md, "One writer at a time".