[esdedev]

Changes made

Adds the wired HyperX Cloud Alpha S (0951:16ed, USB audio control box):

• Sidetone on/off (-s 0 / -s 128), also readable (-s)
• Chat-mix status (-m), from the game/chat balance buttons on the control box
• Microphone mute status (--microphone-mute-status)

Protocol: the control box exposes a vendor collection (usage page 0xff13, usage 0x01) on interface 5. Every command is a 62 byte output report with report ID 0x06; the reply is read with GET_REPORT for the same ID. Byte 10 selects the parameter (0x09 status, 0x07 sidetone), bytes 7–9 are a fixed module id 68 4a 8e. The sidetone command toggles (the 7.1 command 0x02 behaves the same way, checked against the control box LED), so setSidetone reads the status first and only sends it when the state differs; setting the same value twice is a no-op. The device acknowledges by echoing the header with bit 7 set in byte 5. In the status reply, byte 14 bit 0 is sidetone, bit 1 is microphone mute, and bytes 16/20 are the game/chat attenuation in dB (Q8.8, big-endian); chat-mix maps them to steps with the same thresholds HyperX NGENUITY uses.

Tested on Windows 11 with firmware 0x4110: device detection, sidetone get/set on and off, including setting the same value twice (state confirmed by reading it back), chat-mix and mic mute status follow the control box's balance and mute buttons. Unit tests use replies captured from that headset. Not tested on Linux or macOS.

Checklist

• I adjusted the README (if needed)
• For new features in HeadsetControl: I discussed it beforehand in Issues or Discussions and adhered to the wiki — n/a, new device only

[esdedev]

Hi @Sapd, thanks for HeadsetControl!

I'm the owner of the HyperX Cloud Alpha S used for this PR (wired, USB control box, 0951:16ed, firmware 0x4110). Everything was tested on my own headset on Windows 11:

• Sidetone: -s 0 / -s 128 switch it off and on, and setting the same value twice leaves it unchanged (the device's sidetone command toggles, so the driver reads the state first).
• -s reads the current sidetone state back correctly.
• -m (chat-mix) and --microphone-mute-status follow the physical balance and mute buttons on the control box.
• Unit tests pass locally, and the code is formatted with clang-format 18.

I couldn't test on Linux or macOS. If anyone can, I'd appreciate it.

While working on this I also found that the control box can do 7.1 on/off and a 10-band parametric EQ (the EQ is only applied while 7.1 is on). I left those out to keep this PR small, but I'm happy to add parametric EQ in a follow-up if you're interested.

I'm happy to test changes or capture more data from the device. Just let me know.

[Sapd]

Thanks - and thanks for saying up front what you tested and on what.

Checked here: build clean with no warnings, suite green, clang-format 18 clean, README table matches --readme-helper, CI green on all three platforms.

I broke six behaviours to see whether the tests hold, and all six fail:

• always sending the toggle, and inverting the read-first guard → "status query, plus toggle only when needed"
• sidetone flag 0x01 and mute flag 0x02 moved → the respective byte-14 assertions
• flipping the chat-mix direction → "chat-mix level"
• dropping the reply validation → "reply without ack bit should fail"

The toggle guard is the part that would have worried me on a device where setting a value can invert it, and it's the part your tests pin down hardest. Chat-mix direction matches the convention too: game-favoured below 64, chat-favoured above.

Keeping PLATFORM_ALL. The Cloud Alpha 2 Wireless (#590) excluded macOS, but that was because a wrong collection there would write to the wrong interface silently; here reply[4] != 0x9b and the ack bit make a wrong target fail loudly instead, so there's no mechanism for a silent wrong setting.

Two observations, neither blocking:

• All three info capabilities issue their own PARAM_STATUS query, and one reply already carries the sidetone flag, the mute flag and both dB values. So -s -m --microphone-mute-status costs three round trips and ~300 ms where one would do. If you want to cache it, logitech_astro_a50_gen4.hpp and sony_pulse_3d.hpp both keep per-handle state with an onConnectionClosed() hook.
• REPLY_DELAY_MS is a flat 100 ms with no retry, so a single slow reply surfaces as a protocol error rather than being waited out.

On 7.1 and the parametric EQ: yes, please. CAP_PARAMETRIC_EQUALIZER already exists with gain/Q/frequency bands, so the 10-band part should drop straight in. The interesting bit is the coupling you found - if the EQ only applies while 7.1 is on, say so in the device docblock and decide explicitly whether setting the EQ should turn 7.1 on or refuse; I'd rather it refused than changed a setting the user didn't ask for. 7.1 has no capability today, so that one's worth a short issue first.

Merging.