quadcastrgb not detecting microphone

[AlcomedianBlobfish]

So the quadcastrgb utility is claiming that "HyperX Quadcast S isn't connected." even though the microphone very much is and is in use recording on OBS. I believe it's something to do with the device ID, as I saw on a thread linked here that someone couldn't get their microphone to work with OpenRGB because they have a different device ID than the one being used, and sure enough mine matches theirs. Maybe it's a region thing or maybe it's a silent hardware refresh, either way would it be possible to add support for this device ID?

Bus 001 Device 011: ID 03f0:0294 HP, Inc HyperX QuadCast S Bus 001 Device 010: ID 03f0:028c HP, Inc HyperX QuadCast S

[Ors1mer]

The microphone is detected as two separate devices: one for audio input/output, and the second for RGB control. Here I am assuming that the device 011 03f0:0294 you have listed is for RGB control. But it might be otherwise.

From this source file I have found that there are two VID&PID values dependant on the region: one for NA, the other for EU (assuming the author is right). The VendorID you listed matches the EU VID from OpenRGB sources, but the ProductID is different. So it might be a hardware refresh as well.

Answering your question, it is possible and I already added support for both EU PIDs I could find.

Please, compile the sources from the issue branch and comment on whether it works now.

[benwhite1987]

I had the same issue as @AlcomedianBlobfish with the same VID&PID values he posted. I also just purchased my device two weeks ago, so I imagine it is a hardware refresh. I compiled the issue branch as requested and it appears to find the microphone, but gave a Header packet error: Pipe error saying the device might be busy. It also crashed the usb interface for the microphone, requiring me to unplug/replug to bring the microphone back up.

It looks like ID 03f0:0294 is not for RGB control, but rather 03fo:028c as referenced on the OpenRGB issues thread that @AlcomedianBlobfish linked to here. The last comment by 'ButteredCats' has the following:

03f0:028c is the one that seems to make it controllable as using 03f0:0294 outputs [HyperX Quadcast S] Unable to find device with 0 interface (Linux only)

Changed Line #46 in devio.h with alternative PID, recompiled and it worked.

#define DEV_PID_EU2 0x028c /* product ID */

Daemon arguments such as blink and lightning work as expected, but single shot arguments such as solid do not. Microphone just defaults to rainbow cycle with no change in color.

[Ors1mer]

03f0:028c is the one that seems to make it controllable as using 03f0:0294 outputs [HyperX Quadcast S] Unable to find device with 0 interface (Linux only)

Terribly sorry I didn't notice it before. Anyway, I added the right product ID now.

As for the problem with solid (on my device it works fine though), the only reliant solution is to stop writing to the device and just go daemon as in all other modes. I have added the appropriate changes.

@benwhite1987, @AlcomedianBlobfish, it would be great if somebody tested the latest commit of the issue branch to make sure the problem is solved.

[benwhite1987]

@Ors1mer , tested the new commits this morning. Microphone detection is fine, but the solid command still has no effect when used by itself. The solid command works when used in conjunction with another command for upper and lower LEDs, but fails when used by itself, even when trying two separate colors top and bottom. Adding the verbose flag shows packets sent with no errors. When the solid commands fail, no daemon is launched because killall quadcastrgb returns quadcastrgb: no process found and I can run multiple solid commands without getting the error message Another program is using the microphone already. Stopping. as when a daemon launches successfully.

Examples that work: quadcastrgb -u solid ff0000 -l lightning ff6600 quadcastrgb -u blink ff0000 -l solid ff6600

Examples that don't work: quadcastrgb solid ff0000 quadcastrgb -a solid ff0000 quadcastrgb -u solid ff0000 -l solid ff6600

[Ors1mer]

@benwhite1987 the described situation is exactly what is supposed to happen when you run the program from commit 9b6fe6f2c132ae22487848c07d3b9e678a407496, where it detects the microphone but still tries to save the solid data in it. It is different though in 000707d1a1a891c92166f5c69656d6a98e8c4917, where I removed all functionality related to saving the data and made the program always become a daemon so that any other behavior isn't possible.

Now I double-checked it like this:

$ git clone -b 2-quadcastrgb-not-detecting-microphone https://github.com/Ors1mer/QuadcastRGB.git
$ cd QuadcastRGB
$ make quadcastrgb
$ ./quadcastrgb solid
$ ./quadcastrgb solid
Another program is using the microphone already. Stopping.

Thus, solid works as expected. Do these steps give different result in your case?

Also, in order to see what the program transfers to the device, it is possible to compile it with make clean dev and launch ./dev solid; it will write data from packets to stdin. The expected behavior is to send the packets Header display and Data continuously until killed. And it happens for my device.

[benwhite1987]

@Ors1mer you are 100% correct! I botched the git clone this morning before work. Sorry for that. I was building off https://github.com/Ors1mer/QuadcastRGB/commit/9b6fe6f2c132ae22487848c07d3b9e678a407496 with my changes. Your latest commit in https://github.com/Ors1mer/QuadcastRGB/commit/000707d1a1a891c92166f5c69656d6a98e8c4917 works like a charm! Thanks so much for this, I love using this microphone on Linux and having a solid color while recording is significantly less distracting. If you ever need additional help with testing, don't hesitate to reach out.

[Ors1mer]

Glad to know it helped :) I've added the changes to the main branch. Closing the issue now