Headset integrated volume controls not behaving as expected

Ask Fedora
1

Hello everyone,

Introduction
I recently started using Fedora KDE, and it’s been an amazing experience! However, I have one small problem regarding using the integrated volume controls of my headset. Keyboard volume controls work just fine, but my HyperX Cloud Alpha S volume control buttons have weird behaviour, especially when I hold them down to steadily increase volume (see symptoms section for more details).

Question
Is my peripheral just not completely compatible with Linux (works fine on windows)? Or can I do something about it? If I can do something about it, would someone please point me in the right direction?

Symptoms

When I hold the volume-up button of my headset’s integrated button, the UI shows just one tick of volume increase, like if I just pressed the button and immediately released it. However, sound does indeed keep increasing (and vice versa for decreasing volume). At this point, the volume that my headset is producing is not synchronised with what I am seeing in the UI, but if I just tap again on the volume increase, the volume suddenly comes back down and synchronises with the UI.

On another note, if I just tap the headset volume button to increase volume several times, volume does increase. However, in some taps, it increases more than what the UI says, and the next tap brings the volume back down. Like I mentioned in the introduction, keyboard volume controls behave as expected for taps or holds.

I know there is documentation for troubleshooting Fedora audio issues, but nothing seems related to what I described. I might be wrong, so please do let me know if that is the case. I’ll also refrain from putting any audio-related logs here for now, as they can be very big and I do not know if this is a problem worth digging deeper yet.

From what I already debugged, when I tried listening for keystrokes in the terminal, I noticed that holds on the integrated headset volume controls were being registered as presses and immediate releases. Clearly something is not working correctly regarding reading input from the headset volume buttons (but the integrated mute button works fine!).

Thank you in advance for everyone’s time!

2

Because the HyperX Cloud Alpha S is a USB headset, it has its own embedded audio device in the handheld audio control mixer. It also means that the audio chip requires a driver in Linux.

Sometimes the hardware volume control doesn’t line up perfectly with the mixer in the OS. Assuming that you’re using a relatively recent Fedora edition, it’ll be PulseAudio sitting in between KDE and your headset, so PulseAudio’s pactl and pamixer utilities can be used to tweak the range.

If KDE’s audio control offers multiple profiles for the HyperX Cloud Alpha S, try the other profiles to see if it’s a better match.

3

Thank you for the pointer CYL!

After a lot of debugging, I came to the conclusion that this is a potential driver quirk in Linux.

Long story short, the headset is being handled by the HID generic Linux driver, which is properly detecting the events coming from the headset (taps are taps, and holds are holds). But, when the events reach the OS level and, consequently, PipeWire, they are mistranslated. That is, holds become press and immediate release. Then, when the HID driver sends a release event, it appears to be ignored at the OS level.

The mismatch of audio volume between the headset and the OS appears to be just as you said. I tried different profiles, but no dice.

In conclusion, it is hard for me to say if this is a bug or a vendor-specific quirk. But, there is nothing that I can easily do about it. I’ll try to raise an issue in the appropriate channels about a possible mistranslation bug between the HID generic driver and Linux events.

4

Depending on when your headset was manufactured, maybe it could use a firmware update: https://supportcenter.hyperx.com/articles/cloud-alpha-s/cloud-alpha-s-firmware-update/68d6f62c7579af534d711160

5

One small thing I would check before filing it only against PipeWire: run wev (Wayland) or xev (X11, if you use an X11 session) and watch what the headset buttons produce while holding them. If the repeat/release already looks odd there, include that output in the bug report, because it points more toward the input/HID layer than the audio stack.

And if you try the HyperX firmware updater, I would do it from Windows and only with the exact model/revision. USB headset firmware tools are not something I’d run through Wine on a machine I care about.