Corsair Void Pro Wireless (RGB) LED Off breaks mute button

[reffu42]

All of the control options recognize and work fine on my Corsair Void Pro Wireless (RGB) headset. However, when I set the LEDs to off (headsetcontrol -l 0), the mute button on the side of the headset does not work. When LEDs are on:

• Mute button makes a beeping noise when pressed
• When enabled, mic is muted and no sound is measured in various sound settings and measurements

When LEDs are off:

• Mute button does not make a noise when pressed
• Mute button has no effect on mic sensitivity or input

[Sapd]

The command which we have for turning of LEDs, probably does too much (turning of buttons too).

[liolio6]

Hello, I confirm I have a Corsair Void Pro USB and I don't like RGB colors in the side So I use your Soft for disable them : HeadsetControl -l 0 But after this the mute button does not work anymore

Is it possible to fix it ?

Have a good day

[Sapd]

Seems to be related to the issue of this project https://github.com/ckb-next/ckb-next/issues/81

[liolio6]

Okay no solution yet thanks anyway

[Sapd]

So I have now taken another very close look at the protocol. And it's more complex than I thought.

Practically there are two modes, I call them hardware and software modes.

The hardware mode is the standard mode. It allows standard functionality of the buttons, like the mute button. It also turns on the LEDs by default.

The software mode is for when iCue is installed. From here on, the software has to handle the mute functionality and other things.

I have just written some rough support for this. However, the application has to run permanently, there is no other way.

Try the branch Sapd/corsair-void-lightfix. So clone normally, then do git checkout Sapd/corsair-void-lightfix. After compilation, you can start now the software with ./headsetcontrol -s 100 -d It should run, report battery status/connection status etc. and handle the mute button. The LEDs are all off (unfortunately also those of the microphone, I would have to look again here, when I have time).

When you shut down the software normally (with CTRL+C), it will return to hardware mode.

Please test it, so I can possibly include it.

[liolio6]

Hello sorry for the late return I test your fix I launch command :

git clone https://github.com/Sapd/HeadsetControl.git
cd HeadsetControl/
git checkout Sapd/corsair-void-lightfix
mkdir build && cd build
cmake ..
make
./headsetcontrol -s 100 -d

The return of the last command is :

Found Corsair Void (Pro)!

ioctl (SFEATURE): Broken pipe
ioctl (SFEATURE): Broken pipe
ioctl (SFEATURE): Broken pipe
error
unmuted
ioctl (SFEATURE): Broken pipe
muted
ioctl (SFEATURE): Broken pipe
ioctl (SFEATURE): Broken pipe
error
unmuted
ioctl (SFEATURE): Broken pipe
muted

It's working but i don't no if ioctl Broken pipe and error is normal

Anyway good work

[Sapd]

It's working but i don't no if ioctl Broken pipe and error is normal

Normally it should report other things there. Not sure how that can happen. I Probably need to test it again in Linux. But it can also be that a simple restart fixes this.

[VTimofeenko]

For my 0a14 Corsair Void the following happens:

1. Connect the device, leds are on
2. Run ./headsetcontrol -s 0 -d (built from corsair-void-lightfix branch). The leds (including one on the mic) shut off, the log is:

Found Corsair Void (Pro)!

ioctl (SFEATURE): Broken pipe
On Battery
Battery: 171
Battery: 167
Battery: 39
Battery: 167
Battery: 39
Battery: 167

Every time I lower and raise the mic, "Battery" message appears. Sound works just fine.

[Sapd]

Every time I lower and raise the mic, "Battery" message appears. Sound works just fine.

@SabbathHex Ah nice, does the mute button work then?

The battery message belongs to an general status message, and as such is always outputed when it is changed. I can probably catch raising the microphone and mute the mic then too.

Also does Sidetone work as intended?

[VTimofeenko]

@Sapd sorry for being a little ambiguous there :) This headset comes with a microphone that lowers and raises (physically). When it is raised, the headset mutes, when it is lowered - the headset unmutes. That being said, yes, the mute functionality works just fine - no need to catch any extra events.

The headset also has a control on one of the ears that allows changing the sound level. It also works just fine.

Sidetone works perfectly.

[foxt]

It seems like the battery value acts like an internal status value, with in the with the 8th byte being the microphone up value (adding 128 to the "battery"), and the other 7 bytes being the actual battery, which is unreliable when connected to power, slowly ramping up to 100% over a few seconds. Plugging the headset into power sometimes results in Loading to be outputted to console.

The headset has a completely different system for raising and lowering the microphone, raising the microphone will always mute and unmute the headphones microphone, and does not cause muted or unmuted to sh-ow up in console, breaking HeadsetControl's internal track if the device is muted, causing the side button to behave unexpectedly. If the headset was unmuted by headsetcontrol, the microphone goes up, the microphone gets muted by the headset, and when it comes back down, it gets unmuted again by the headset, and side button behavior works as intended, however if the headset was muted by headsetcontrol, the microphone goes up, and comes back down, the headset gets unmuted, and pressing the side button again, unmutes it, effectively doing nothing except for going beep boop, which can cause confusion because the microphone muted value is inverted from what the user expects. The button can also be pressed when the microphoone is up, which does nothing except output in console muted/unmuted.

The way to sort it is by listening for the battery event, which gets emitted when the mic gets moved., checking if the 8th bit is 1, and if so, the microphone is up, headset is muted, and cannot be unmuted, until this bit changes to 0, as this is handled by the headset itself, and when the bit is 0 headsetcontrol can do what ever it wants to the muted state.

Also, the headset muted light never turns on when headsetcontrol -d is running. Sidechain works fine.

[antonioGlavocevic]

Is there a way to have the application run on boot and in the background constantly? I have tried with @reboot in cron but no luck.

[Sapd]

@theLMGN Thanks, I will incoperate the changes when I have time.

@antonioGlavocevic You probably need a systemd script. E.g. create a file like ~/.config/systemd/user/headsetcontrol.service and write into it

[Unit]
Description=Headsetcontrol

[Service]
ExecStart=/path/to/headsetcontrol -d -s 128

[Install]
WantedBy=default.target

If you used make install, you can determine the path to it by typing which headsetcontrol

You can enable auto-start then by typing systemctl --user enable headsetcontrol and start it directly with systemctl --user start headsetcontrol

[antonioGlavocevic]

@Sapd Thanks, I have it working automatically now.

I thought I might just mention incase someone has a similar problem: the rules files are different compared to the master branch and I had to add my device (idProduct 1b23) to 70-headsets.rules when I initially set this up.

However this was givng me the following error in systemd during auto-start:

May 09 13:54:25 laptop-popos systemd[1679]: Started Headsetcontrol.
May 09 13:54:25 laptop-popos systemd[1679]: headsetcontrol.service: Main process exited, code=exited, status=1/FAILURE
May 09 13:54:25 laptop-popos systemd[1679]: headsetcontrol.service: Failed with result 'exit-code'.

It was working using systemctl --user start headsetcontrol though.

Solved this by removing that 70-headsets.rules file and copying one of the 50-rules but changing to my idProduct.

[SlippyDong]

@Sapd Hi, thanks for this great little tool. It's exactly what I was looking for, but unfortunately I ran into the same issue with the mic button not working when the RGB light is off. Any chance you could build a windows executable with the void light fix or can I do this myself somehow?

Thanks either way!

[Sapd]

@SlippyDong I merged master into the branch, you can now download it's Windows build directly here (scroll down to Artifacts): https://github.com/Sapd/HeadsetControl/actions/runs/4909178509

You can try it then with headsetcontrol.exe -d (and optionally specifying a sidetone with -s)

However otherwise I didn't continue working on the branch. I have some ideas of how to make it more clean, however there is still the open question of how to accept input during program runtime (or simply let the user exit and specify new input)

[SlippyDong]

@Sapd Thanks for your quick response. Really appreciate it. B.T.W. I found this project via another Github project that builds upon this one, which adds a gui and battery indicator in the Windows system tray and I don't think you've got it listed yet on your main page: [https://github.com/LeoKlaus/HeadsetControl-GUI/releases]

I've just tried the version you just built but unfortunately I get an error:

C:\Users\star\Downloads\headsetcontrol>headsetcontrol.exe -d Found Corsair Headset Device! Success! Failed activating void software mode Failed to set/request (null). Error: -1: WriteFile: (0x00000001) Incorrect function.

If I can provide more details in any way then please tell me how I can provide them to you. I've got VScode (just a beginner Python developer) and am fairly experienced with pc's in general, so if I can run anything then please let me know.

[Sapd]

@SlippyDong I forgot to specify the usageID.

Can you try this one (most probably the correct one) ? https://github.com/Sapd/HeadsetControl/actions/runs/4909398952

If it does not work, I also compiled one with another ID: https://github.com/Sapd/HeadsetControl/actions/runs/4909383889

If you also want to take a look at the software, here is a tutorial for compiling on Windows: https://github.com/Sapd/HeadsetControl/wiki/Development#windows

Edit: It could be that there is still the problem, that than one packet succeeds in getting through, the other not. That will take a bit more time to fix

[SlippyDong]

@Sapd Thanks mate, https://github.com/Sapd/HeadsetControl/actions/runs/4909398952 works perfectly.

I've done a few tests and here are the results:

• First: open terminal and run headsetcontrol.exe -d > this disables the lights and prints a message as below.
• The mute button works and I can close the terminal and it keep the lights off and mic muted after terminal closes.
• The mute button won't work when the terminal is closed, but the mic remains in the last state you set it to (on or off)
• To enable/disable mic button again, I just need to run or doubleclick headsetcontrol.exe
• The battery status is updated on every change in the terminal as long as the terminal window remains open.

There is an error printed every time I press the mute/unmute button, but this doesn't seem to affect anything. (since the corsair void will beep once the battery starts getting low, a visual indicator in the system tray isn't really necessary anyway, so it's not really that important to have a GUI or systray icon)

Here's what happens in the terminal when I run the app:

PS C:\Users\star\Downloads\headsetcontrol.exe> .\headsetcontrol.exe -d Found Corsair Headset Device! error unmuted On Battery Battery: 69 muted error unmuted Battery: 67

All in all this is great! No more ICUE memory hog to disable the RGB in my headset. I even considered unsoldering the RGB wires from the PCB yesterday as they are quite easily accessible, but this is a better solution. Many thanks again!

[Sapd]

Any time!

• The mute button won't work when the terminal is closed

Yep, thats expected with this mode. When the software mode is activated, the software has to care about the mute button

There is an error printed every time I press the mute/unmute button, but this doesn't seem to affect anything.

I think thats because the Sidetone command is probably erroring out (its a bit more elaborate to fix). Given that you don't want to set it, it does not have any effect.

I even considered unsoldering the RGB wires from the PCB yesterday as they are quite easily accessible, but this is a better solution. Many thanks again!

Didn't think at the beginning, that many people will actually use it on Windows. Quite nice to hear!

B.T.W. I found this project via another Github project that builds upon this one, which adds a gui and battery indicator in the Windows system tray and I don't think you've got it listed yet on your main page: [https://github.com/LeoKlaus/HeadsetControl-GUI/releases]

Looks indeed quite nice, I noticed I already starred it. The author can make any time a pull request for including it (I don't want to make it from my side, as I don't know if he still is maintaining it).

[SlippyDong]

Made a little vbscript that will run headsetcontrol.exe -d and keeps the terminal window hidden and keeps the mute button functional. I've added this to the startup folder so now the headsetcontrol switches off RGB on startup and remains active in the background with minimal resources (424Kb). For anyone else interested in running this on startup as well, here's the steps:

• Create a text file on your desktop and copy paste the following ( replace C:\headsetcontrol\headsetcontrol.exe with whatever your location and file name is, but leave all the """ quotes intact - they are used by vbscript for handling the file path):

Set WshShell = CreateObject("WScript.Shell") WshShell.Run """C:\headsetcontrol\headsetcontrol.exe"" -d", 0, False

• Save the file as: DisableRGB.vbs
• Click start > Run > shell:common startup > press enter.
• Move DisableRGB.vbs to the startup folder you've just opened in the last step. (Windows will ask for permission > accept)

Now, when you restart your computer the RGB will switch off, the mute button stays functional and there is no terminal window anymore. The process can be manually killed in process explorer if you should want to:

[github-actions[bot]]

This issue is stale because it has been open 300 days with no activity. Remove stale label or comment or this will be closed in 60 days.

[github-actions[bot]]

This issue was closed because it has been stalled with no activity.