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
ckb-next/ckb-next#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.