Skip to content

JSON/YAML/ENV incorrect output #410

Open
Open
JSON/YAML/ENV incorrect output#410
Labels
bug

Description

@p3lim
p3lim
opened on Jul 4, 2025

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

Activity

  1. p3lim
    added
    bug
    on Jul 4, 2025

  2. ModoloDev commented on Jul 10, 2025

    @ModoloDev
    ModoloDev
    on Jul 10, 2025
    Contributor

    I’ve opened a PR, fixing this problem.
    Could you please test it?

  3. p3lim commented on Jul 13, 2025

    @p3lim
    p3lim
    on Jul 13, 2025
    Author

    @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

  4. ModoloDev commented on Jul 13, 2025

    @ModoloDev
    ModoloDev
    on Jul 13, 2025
    Contributor

    @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.

  5. ModoloDev commented on Jul 13, 2025

    @ModoloDev
    ModoloDev
    on Jul 13, 2025
    Contributor

    @p3lim
    I just dropped a new update. Could you please test it?

  6. p3lim commented on Jul 13, 2025

    @p3lim
    p3lim
    on Jul 13, 2025
    Author

    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.

  7. ModoloDev commented on Jul 13, 2025

    @ModoloDev
    ModoloDev
    on Jul 13, 2025
    Contributor

    Querying hangs for about a second or two, but it consistently reports correctly both for -b and -o now 👍

    Well... better slow than wrong I guess hahaha
    The problem is, when -o is used, it queries each info twice

  8. ModoloDev commented on Jul 13, 2025

    @ModoloDev
    ModoloDev
    on Jul 13, 2025
    Contributor

    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.

    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.

  9. ModoloDev commented on Jul 13, 2025

    @ModoloDev
    ModoloDev
    on Jul 13, 2025
    Contributor

    @p3lim
    Do you have the Audeze HQ app open?

  10. p3lim commented on Jul 13, 2025

    @p3lim
    p3lim
    on Jul 13, 2025
    Author

    No, wasn't aware of any app that worked on Linux.

  11. ModoloDev commented on Jul 13, 2025

    @ModoloDev
    ModoloDev
    on Jul 13, 2025
    Contributor

    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");

  12. p3lim commented on Jul 14, 2025

    @p3lim
    p3lim
    on Jul 14, 2025
    Author

    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.

  13. ModoloDev commented on Jul 14, 2025

    @ModoloDev
    ModoloDev
    on Jul 14, 2025
    Contributor

    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.

  14. p3lim commented on Jul 14, 2025

    @p3lim
    p3lim
    on Jul 14, 2025
    Author

    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

  15. ModoloDev commented on Jul 14, 2025

    @ModoloDev
    ModoloDev
    on Jul 14, 2025
    Contributor

    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.

  16. p3lim commented on Jul 14, 2025

    @p3lim
    p3lim
    on Jul 14, 2025
    Author

    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

  17. ModoloDev commented on Jul 14, 2025

    @ModoloDev
    ModoloDev
    on Jul 14, 2025
    Contributor

    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?

  18. p3lim commented on Jul 14, 2025

    @p3lim
    p3lim
    on Jul 14, 2025
    Author

    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.

  19. ModoloDev commented on Jul 14, 2025

    @ModoloDev
    ModoloDev
    on Jul 14, 2025
    Contributor

    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.

  20. Sapd commented on Jul 14, 2025

    @Sapd
    Sapd
    on Jul 14, 2025
    Owner

    Indeed querying twice should not happen

  21. ModoloDev commented on Jul 14, 2025

    @ModoloDev
    ModoloDev
    on Jul 14, 2025
    Contributor

    @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?

  22. p3lim commented on Jul 14, 2025

    @p3lim
    p3lim
    on Jul 14, 2025
    Author

    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

  23. ModoloDev commented on Jul 14, 2025

    @ModoloDev
    ModoloDev
    on Jul 14, 2025
    Contributor

    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.

  24. Sapd commented on Jul 15, 2025

    @Sapd
    Sapd
    on Jul 15, 2025
    Owner

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions