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.

6

I have the exact same headset, and I’m having the exact same problem. The thing that bothers me is every time I boot, my headset goes to ~50% of its volume independent of the system volume, so if the system is on 50% now, my real volume is ~25%; if I bump the system volume to 100%, the real volume is now ~50%. The only workaround that I found is maxing out the volume by repeatedly clicking the DAC volume up till 100% (which makes the system volume also go up, so there is some sort of communication), and then, when both real and system volume are stable at 100%, I’m able to use it normally, controlling it by the system.

Fedora 44, Kernel 7.1.13-200.fc44.x86_64

7

I have found a fix for my problem of headset volume resetting independent of system volume every reboot.
After ignoring the problem for a while and dealing with it by clicking the volume up button on the headset after every reboot, I stumbled into the solution today.
The thing is alsamixer does control the headset, but, somehow, sudo alsactl store simply does not work for some weird reason, so we need to store the settings some other way and then auto-restore it by using a .desktop file (Thanks to Sergiy Kolodyazhnyy for answering this)

  • First run alsamixer on the terminal
  • Press F6 and select HyperX Cloud Alpha S (or the name of your headset) from the list.
  • With the arrow keys, select the correct volume 0 dB gain (by default this was -16 dB every boot, thus my problem).
    This is my config:
    Captura_de_tela_20261005_222335
    Captura_de_tela_20261005_222335907×479 208 KB
  • Press ESC and run alsactl --file ~/.config/goodalsamixer.state store this will save the current mixer state to a file.
  • Now create a .desktop file in the autostart directory like this nano .config/autostart/alsaautorestore.desktop (you might need to create the autostart folder)
  • Paste the following code
[Desktop Entry]
Type=Application
Terminal=false
Name=alsaautorestore
Exec=alsactl --file ~/.config/goodalsamixer.state restore
  • Save and done !

Now you can reboot and your headset will not be extra quiet every startup ! :slight_smile:

8

Thank you for the suggestion!

Unfortunately, this still does not solve the original problem, which is driver related.

I do find it weird however, because I never experienced your problem of the headset being super quiet. Although, I usually have my system sound at around 20%, so maybe I never noticed. And I cannot handle anywhere near 100% because it is way too loud.