This is actually the developer forum for Jabra devices, for product (Xpress) questions you will probably need to consult jabra.com/support for more information.
That being said (or written), we might be able to help qualify your question to see you get to the right resouces for help.
Could you elaborate a little more on what you are trying to achieve, the environment etc.?
If you prefer to do this a little more private, please raise a supoprt ticket in the support section of this site.
I've done some investigation here:
The short answer is that it is unfortunately not possible to determine the mute-state of the device through the API. (This is very close to the original USB HID spec for telephony devices.)
This applies to all platforms, and run-time environment adapters (eg node.js).
The mute-button on the devices are seen as a toggle-switch, which can fire events during an active call (ie. device state is off-hook).
We previously had an error in the implementation of the APIs that seemingly also returned the mute-state (this was fixed recently).
It is up to the application (softphone etc) to set the mute-state of devices from what the app believes is the master state during active calls.
On some of our devices, there are additionally device-local means (eg buttons) of muting the device.
These will often mute the device, even if not in the off-hook state, for example when an audio-stream is opened to the device through the audio interface of the USB sub-system.
It is, however, not possible to detect via an API function if the local mute is enabled.
It should be noted, that if the device is locally muted, the device will locally un-mute if the devices goes off-hook through an API interaction.
The only exception to this is if the mute-switch is a mechanical two-state switch, as for example moving the boom-arm on the Evolve 75 to vertical.
In that case, the device will stay muted until the boom-arm is lowered again.
Although I don't think it is what you were looking for, I hope it clarifies the situation.
version 22.214.171.124 does contain a fix for the 100% CPU consumption issue.
In fact, we have been unable to reproduce the behaviour on applications linked with the new core libraries from 1.8 and onwards.
The current production release of Jabra Direct is using a slightly older version of the core libraries (1.7.9.x), and this is most likely why we see the behaviour with Direct. The behaviour is also likely to disappear when Direct is upgraded later in the spring to use version 1.8.x or later.