Sapd
JSON/YAML/ENV incorrect output
Description
When I query headsetcontrol -b I get the correct output:
Found 1 supported device(s):
Audeze Maxwell (Audeze Maxwell Dongle) [0x3329:0x4b19]
Battery:
Status: BATTERY_AVAILABLE
Level: 86%
When I query headsetcontrol -o yaml (or json or env) I get an incorrect battery reading:
---
name: "HeadsetControl"
version:
api_version: "1.3"
hidapi_version: "0.14.0"
device_count: 1
devices:
- status: "success"
device: "Audeze Maxwell"
vendor: "Audeze LLC"
product: "Audeze Maxwell Dongle"
id_vendor: "0x3329"
id_product: "0x4b19"
capabilities:
- CAP_SIDETONE
- CAP_BATTERY_STATUS
- CAP_INACTIVE_TIME
- CAP_EQUALIZER_PRESET
- CAP_VOLUME_LIMITER
capabilities_str:
- sidetone
- battery
- inactive time
- equalizer preset
- volume limiter
battery:
status: "BATTERY_UNAVAILABLE"
level: -1
This in turn makes the Gnome extension unable to function.
Running 3.1.0 from nixpkgs with the following override:
(pkgs.headsetcontrol.overrideAttrs (old: {
src = pkgs.fetchFromGitHub {
owner = "Sapd";
repo = "HeadsetControl";
rev = "3.1.0";
sha256 = "sha256-9LUqYV0MMTtlFYZCEn81kML5F46GDYWYwoKpO0UORcQ=";
};
# disable patch that was applied for 3.0.0 since it's been merged in 3.1.0
patches = [];
}))
I'd be more than happy to test PRs.
On which OS does the problem happen?
Linux
@ModoloDev -o yaml still reporting "BATTERY_UNAVAILABLE", but it might be affected by the following.
Now when querying with -b the battery status is "BATTERY_UNAVAILABLE" for the first query, correct on the second, and "BATTERY_UNAVAILABLE" for any subsequent queries:
> headsetcontrol -b
Found 1 supported device(s):
Audeze Maxwell (Audeze Maxwell Dongle) [0x3329:0x4b19]
Battery:
Status: BATTERY_UNAVAILABLE
> headsetcontrol -b
Found 1 supported device(s):
Audeze Maxwell (Audeze Maxwell Dongle) [0x3329:0x4b19]
Battery:
Status: BATTERY_AVAILABLE
Level: 58%
> headsetcontrol -b
Found 1 supported device(s):
Audeze Maxwell (Audeze Maxwell Dongle) [0x3329:0x4b19]
Battery:
Status: BATTERY_UNAVAILABLE
> headsetcontrol -b
Found 1 supported device(s):
Audeze Maxwell (Audeze Maxwell Dongle) [0x3329:0x4b19]
Battery:
Status: BATTERY_UNAVAILABLE
@p3lim I'm dropping a new update soon with a different way to request the headset status. hope it'll fix it. I'll let you know.
Querying hangs for about a second or two, but it consistently reports correctly both for -b and -o now 👍
Edit: spoke too soon, it will still randomly report as unavailable, most notably with the gnome extension as it queries very frequently.
Querying hangs for about a second or two, but it consistently reports correctly both for
-band-onow 👍
Well... better slow than wrong I guess hahaha
The problem is, when -o is used, it queries each info twice
Querying hangs for about a second or two, but it consistently reports correctly both for
-band-onow 👍Edit: spoke too soon, it will still randomly report as unavailable, most notably with the gnome extension as it queries very frequently.
Oh, I posted just before you edited your message. That's weird, it shouldn't behave like that. I'm getting the correct info every time in my tests.
I'm testing on Windows, so Idk.
Ok, so could you help me to debug it?
On line 182 in audeze_maxwell.c file, add this code and send me what gets printed, please:
for (int i = 0; i < 5; ++i) {
for (int j = 0; j < MSG_SIZE; ++j) {
printf("%02x", status_buffs[i][j]);
if (j < MSG_SIZE - 1) {
printf(" ");
}
}
printf("\n");
}
printf("=========================================================================================================================================================================================\n");
I'll test after work, but in the mean time could you provide this as a patch file (maybe in a gist)? That way I can just plug it directly into my nix config along with the PR.
Yeah, ofc.
https://gist.github.com/ModoloDev/5b064a592f87b31a441074d1e5ee6735
Oh, and I was thinking... How frequently does your gnome extension query? That could be the problem.
https://gist.github.com/ModoloDev/5b064a592f87b31a441074d1e5ee6735
I'm sorry, I did mean an actual patch file, i.e. from git diff.
The patch file I use for the PR is https://patch-diff.githubusercontent.com/raw/Sapd/HeadsetControl/pull/412.patch, just for reference.
This is how I install the software using nix:
home.packages = with pkgs; [
(headsetcontrol.overrideAttrs (old: {
# bump version to 3.1.0, latest in nix repos = 3.0.0
src = pkgs.fetchFromGitHub {
owner = "Sapd";
repo = "HeadsetControl";
rev = "3.1.0";
sha256 = "sha256-9LUqYV0MMTtlFYZCEn81kML5F46GDYWYwoKpO0UORcQ=";
};
# disable patch that was applied for 3.0.0 since it's been merged in 3.1.0
patches = [
# add new patch for our headphones
(pkgs.fetchpatch {
url = "https://patch-diff.githubusercontent.com/raw/Sapd/HeadsetControl/pull/412.patch";
hash = "sha256-yi8jCs7lJuHSfwgodlt5yHBwoAWBWCwWNl6sOm1Nn6o=";
})
];
}))
];
How frequently does your gnome extension query?
Looks like it's every 5 minutes, and every time the gnome menu/panel is opened/modified (the latter here is probably what's causing too frequent updates), and it queries multiple times when it does a query (but I'm no expert when it comes to gnome extensions). It's this one: https://github.com/ChrisLauinger77/gnome-shell-extension-HeadsetControl
So it won't work. I'd need it to be debugged. 5 min intervals shouldn't be a problem. I'm using a windows extension (https://github.com/LeoKlaus/HeadsetControl-GUI) with 30s intervals. Maybe it's querying with -o and -b at the same time, it'd probably cause problems.
Maybe it's querying with -o and -b at the same time, it'd probably cause problems.
Doesn't look like it: https://github.com/ChrisLauinger77/gnome-shell-extension-HeadsetControl/blob/v48.13/HeadsetControl%40lauinger-clan.de/extension.js#L1039-L1041
Yeah, you're right. In the docs, there's a debugging section - https://github.com/ChrisLauinger77/gnome-shell-extension-HeadsetControl/tree/v48.13?tab=readme-ov-file#debugging
Could you send me the result of that, please?
Starting a fresh wayland sub-session (i.e. basically the same as rebooting and starting Gnome) with debugging enabled I see this:
GNOME Shell-Message: 18:15:04.242: HeadsetControl Refreshing...
GNOME Shell-Message: 18:15:04.696: HeadsetControl Quicksettings not open - do nothing...
GNOME Shell-Message: 18:15:05.008: HeadsetControl Refreshing...
GNOME Shell-Message: 18:15:05.369: HeadsetControl Quicksettings not open - do nothing...
GNOME Shell-Message: 18:15:05.522: HeadsetControl device_count: 1
GNOME Shell-Message: 18:15:05.522: HeadsetControl devices(0).status: success
GNOME Shell-Message: 18:15:05.522: HeadsetControl Audeze Maxwell
GNOME Shell-Message: 18:15:05.523: HeadsetControl setMenuHeader: Battery and Chatmix
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterylow
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strcolor: rgb(246,97,81)
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterymedium
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strSettingsColor: color-batteryhigh
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:05.523: HeadsetControl _changeColor: 100
GNOME Shell-Message: 18:15:05.523: HeadsetControl _changeColor: #ffffff
GNOME Shell-Message: 18:15:05.523: HeadsetControl JSON refresh completed successfully
GNOME Shell-Message: 18:15:05.523: HeadsetControl setMenuHeader: Battery and Chatmix
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterylow
GNOME Shell-Message: 18:15:05.523: HeadsetControl _getColorHEXValue-strcolor: rgb(246,97,81)
GNOME Shell-Message: 18:15:05.524: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterymedium
GNOME Shell-Message: 18:15:05.524: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:05.524: HeadsetControl _getColorHEXValue-strSettingsColor: color-batteryhigh
GNOME Shell-Message: 18:15:05.524: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:05.524: HeadsetControl _changeColor: 100
GNOME Shell-Message: 18:15:05.524: HeadsetControl _changeColor: #ffffff
GNOME Shell-Message: 18:15:05.524: HeadsetControl _changeIndicatorVisibility - headset connected - show indicator
GNOME Shell-Message: 18:15:09.535: HeadsetControl device_count: 1
GNOME Shell-Message: 18:15:09.535: HeadsetControl devices(0).status: success
GNOME Shell-Message: 18:15:09.535: HeadsetControl Audeze Maxwell
GNOME Shell-Message: 18:15:09.535: HeadsetControl setMenuHeader: Battery and Chatmix
GNOME Shell-Message: 18:15:09.536: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterylow
GNOME Shell-Message: 18:15:09.536: HeadsetControl _getColorHEXValue-strcolor: rgb(246,97,81)
GNOME Shell-Message: 18:15:09.536: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterymedium
GNOME Shell-Message: 18:15:09.536: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:09.536: HeadsetControl _getColorHEXValue-strSettingsColor: color-batteryhigh
GNOME Shell-Message: 18:15:09.536: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:09.536: HeadsetControl _changeColor: -1
GNOME Shell-Message: 18:15:09.536: HeadsetControl _changeColor: #f66151
GNOME Shell-Message: 18:15:09.537: HeadsetControl JSON refresh completed successfully
GNOME Shell-Message: 18:15:09.537: HeadsetControl setMenuHeader: Battery and Chatmix
GNOME Shell-Message: 18:15:09.537: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterylow
GNOME Shell-Message: 18:15:09.538: HeadsetControl _getColorHEXValue-strcolor: rgb(246,97,81)
GNOME Shell-Message: 18:15:09.538: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterymedium
GNOME Shell-Message: 18:15:09.538: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:09.538: HeadsetControl _getColorHEXValue-strSettingsColor: color-batteryhigh
GNOME Shell-Message: 18:15:09.538: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:09.538: HeadsetControl _changeColor: -1
GNOME Shell-Message: 18:15:09.538: HeadsetControl _changeColor: #f66151
GNOME Shell-Message: 18:15:09.538: HeadsetControl _changeIndicatorVisibility - headset not connected - hide indicator
GNOME Shell-Message: 18:15:28.251: HeadsetControl Refreshing...
GNOME Shell-Message: 18:15:28.877: HeadsetControl Quicksettings not open - do nothing...
GNOME Shell-Message: 18:15:29.532: HeadsetControl device_count: 1
GNOME Shell-Message: 18:15:29.532: HeadsetControl devices(0).status: success
GNOME Shell-Message: 18:15:29.532: HeadsetControl Audeze Maxwell
GNOME Shell-Message: 18:15:29.532: HeadsetControl setMenuHeader: Battery and Chatmix
GNOME Shell-Message: 18:15:29.532: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterylow
GNOME Shell-Message: 18:15:29.532: HeadsetControl _getColorHEXValue-strcolor: rgb(246,97,81)
GNOME Shell-Message: 18:15:29.532: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterymedium
GNOME Shell-Message: 18:15:29.532: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:29.532: HeadsetControl _getColorHEXValue-strSettingsColor: color-batteryhigh
GNOME Shell-Message: 18:15:29.533: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:29.533: HeadsetControl _changeColor: 100
GNOME Shell-Message: 18:15:29.533: HeadsetControl _changeColor: #ffffff
GNOME Shell-Message: 18:15:29.533: HeadsetControl JSON refresh completed successfully
GNOME Shell-Message: 18:15:29.533: HeadsetControl setMenuHeader: Battery and Chatmix
GNOME Shell-Message: 18:15:29.533: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterylow
GNOME Shell-Message: 18:15:29.533: HeadsetControl _getColorHEXValue-strcolor: rgb(246,97,81)
GNOME Shell-Message: 18:15:29.534: HeadsetControl _getColorHEXValue-strSettingsColor: color-batterymedium
GNOME Shell-Message: 18:15:29.534: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:29.534: HeadsetControl _getColorHEXValue-strSettingsColor: color-batteryhigh
GNOME Shell-Message: 18:15:29.534: HeadsetControl _getColorHEXValue-strcolor: rgb(255,255,255)
GNOME Shell-Message: 18:15:29.534: HeadsetControl _changeColor: 100
GNOME Shell-Message: 18:15:29.534: HeadsetControl _changeColor: #ffffff
GNOME Shell-Message: 18:15:29.534: HeadsetControl _changeIndicatorVisibility - headset connected - show indicator
it refreshes a couple of times, and it gets the battery status. Then after 4 seconds it does a new refresh and the JSON is borked (so it hides the indicator). After ~20 seconds I manually open the panel and it refreshes again (as expected), this time it gets valid data. Every time I open/close the panel it queues a refresh (async), which will just spam the commands and end up being invalid.
From what I understand is that the headphones will not respond with valid data if queried too often, so I feel like this could be solved by caching the last result, then if the query happens within the interval it just responds with the cached data instead of querying for live data.
I assume this limit is only on battery status though.
Caching or just not spamming/sending too often. But, yeah, unfortunately Audeze Maxwell firmware has some limitations. Every packet sent to it must be in a ~60ms interval, and unlike other brands/headsets, all communication is made by reports, no interruptions involved, and lots of packets must be sent for correct output. Maxwell's "protocol" really sucks hahaha
Therefore, I couldn't find a better way to bring the correct results, and I think all these caching process can't be implement on the Headset Control part, it's out of scope.
One thing that could be improved is preventing the -o command from querying each piece of information twice. Maybe it’s a bug, I’m not sure. Perhaps @Sapd can shed some light on this.
@Sapd, I’ve fixed this in the latest commit for #412. I think it would be a good idea to test the changes in various scenarios to prevent unexpected side effects, could you help me with that, please?
Seems very consistent now, I can put it in a while; true loop and it will output correctly most of the time, but that's pushing it.
Edit: that's with -o json
Seems very consistent now, I can put it in a while; true loop and it will output correctly most of the time, but that's pushing it.
Edit: that's with
-o json
Thanks for testing it. That's the best I could do. I’ve documented everything, including all the packets used, for future improvements.
@Sapd, I’ve fixed this in the latest commit for #412. I think it would be a good idea to test the changes in various scenarios to prevent unexpected side effects, could you help me with that, please?
Yeah the line you removed should definitely not be there. Not sure how it got there, couldn't trace it down on a first glance with git blame. Cannot throughly test it this week, but we will see if issues arrive