onHeadsetStateChanged MONO_OFF/MONO_ON not firing

15 posts / 0 new

Wed, 04/29/2020 - 08:17

tsicbergman

System

OS: Windows 10 Enterprise Version 1903 Build 18362.720
Plantronics HUB: Version 3.16.1 | Build 9293
Headset: Voyager Focus UC. Firmware v.366
BT600: Firmware v.1723

onHeadsetStateChanged had been firing whenever the headset would change between media mode (purple dongle) and call mode (blue dongle) - or rather, when the headset would change between MONO_OFF and MONO_ON, respectively.

After updating to the latest BT600 firmware (prior was v.1615) these state changes are no longer firing. Other state changes are firing as expected, such as mute and unmute, dock and undock, but the switch between modes (media and call - MONO_OFF, MONO_ON) is not.

I found another headset still with v.1615 of the firmware and the MONO_OFF and MONO_ON events fired as expected.

Thu, 04/30/2020 - 08:08

lcollins

Hi, I have been able to reproduce this issue so we will look into it. In the meantime, could you let me know for what scenario you need the monoon/monooff events? Thanks, Lewis.

Thu, 04/30/2020 - 10:16

(Reply to #2) #3

tsicbergman

Lewis, I would love to explain the scenario where we need the MONO_ON/MONO_OFF events. As you might expect, we're making use of the Plantronics SDK (C++ native) to incorporate headset actions into a custom softphone application. We noticed some time ago that the headset would enter different modes when on and off a call. Eventually we narrowed this down to the headset switching between its two modes – media mode and call mode. Or MONO_OFF and MONO_ON, respectively. The problem lies in the fact that the two modes have completely independent device/master volume levels. So, for example, say your headset is in media mode (MONO_OFF) and you have adjusted the device volume to be 50%. You’re listening to music at a nice comfortable level on your favorite music streaming service. Then, you get an incoming call. The headset switches to call mode (MONO_ON). Call mode’s device volume is 100%. The headset volume raises to 100%, as does your music (as apps, or audio sessions, move relative to the device volume). This causes you to briefly go deaf as you hurry to remove the headset from your ears and adjust the volume back down to where you thought you had had it – 50%. This is the experience on a Windows machine. I don't know how it's handled on a Unix-based machine. To try to tame the differences in device volume levels between the two headset modes, we’re attempting to keep the two volumes in sync using a combination of headset events and system/volume events. We’re using the MONO_ON/MONO_OFF events raised from IDeviceListenerCallback::onHeadsetStateChanged to know when the headset has switched modes in order to know when to re-sync the volume back to where the User expects it to be - at the nice comfortable level they last left it. If there was a means to disable this mode switch – to always be in one or the other – that would be ideal. If there exists a known, or easier, path to achieve this, I’m all ears. If you are able, please see Poly Case Number 07454127 for further details in the journey leading up to this point. But the above is the gist of it. Thank you Lewis, Caleb. P.S. These forum posts really need to support better formatting. Having everything run together makes it very difficult to read.

Thu, 04/30/2020 - 13:10

(Reply to #3) #4

tsicbergman

IDeviceEventsCallback::onAudioStateChanged is also no longer firing when switching between modes.

Fri, 05/01/2020 - 07:24

lcollins

Hi Caleb, I have found a workaround. Take a look at the update I just applied to this sample code file: https://github.com/plantronics/pdc/blob/master/Advanced/ResilientPLTDemo/ResilientPLTDemo/HubSDKConnector.cs. The function _deviceComEvents_onDataReceived is now able to detect the media states: (monoon / on a call), (mediaon / playing music) and (monooff / media off). This code is in C#, but if you handle the onDataReceived callback in your C++ code, you should be able to directly port this approach. Let me know. Thanks, Lewis.

Fri, 05/01/2020 - 07:27

(Reply to #5) #6

lcollins

One more thing it's worth mentioning: the colouration of the BT600 LEDs has changed since the latest firmware update v.1723. The new colour scheme is documented here: https://www.plantronics.com/us/en/support/knowledge-base/kb-article-page?type=Product_Information__kav&lang=en_US&urlName=BT600-Firmware-Release-Notes

Fri, 05/01/2020 - 10:50

(Reply to #6) #7

lcollins

Hi Caleb, Further to my last post, I have now applied the same update to the Native Library C++ sample code, here: https://github.com/plantronics/pdc/blob/master/C%2B%2B%20Native%20Sample/PLTCPlusPlusNativeSample/PLTCPlusPlusNativeSample/PLTCPlusPlusNativeSample.cpp. You can use this example to see how to implement the logic to receive those audio status events. Take a look at the onDataReceived function, and how the event sink it is contained in is registered, with DMResult result = activeDevice->registerCallback(&deviceCallback); Let me know if this helps.

Fri, 05/01/2020 - 11:27

(Reply to #7) #8

tsicbergman

Lewis, I appreciate the workaround, and I was able to implement it on BT600 firmware v.1723 using your base C# example. However, it'd be best if a firmware patch was released to re-implement the IDeviceListenerCallback::onHeadsetStateChanged and IDeviceEventsCallback::onAudioStateChanged MONO_OFF/MONO_ON events like they were in previous firmware versions. It's rather inconvenient to have a documented API change out from under you like that. Unfortunately all of this doesn’t help to resolve the primary issue of the volume change behavior we’re experiencing - which I can elaborate more on, here, if you’d like, but it’s a bit outside the scope of this particular forum post, and would be a bit difficult to follow with the lack of basic formatting in these posts. Thank you, Caleb

Sat, 05/02/2020 - 15:50

(Reply to #8) #9

lcollins

Hi Caleb, I will take another look at the behaviour in the old bt600 firmware in respect of those 2 callbacks you mention: IDeviceListenerCallback::onHeadsetStateChanged and IDeviceEventsCallback::onAudioStateChanged. In order to inform a potential fix. Thanks, Lewis

Mon, 05/04/2020 - 03:16

(Reply to #9) #10

lcollins

I have now done a further round of testing on this and shared with firmware team. Once I get feedback on progress of a fix I will advise.

Mon, 05/04/2020 - 08:12

(Reply to #10) #11

tsicbergman

Thank you, Lewis. I appreciate your diligence in correcting this matter.

Mon, 05/11/2020 - 02:47

(Reply to #11) #12

lcollins

Hi Caleb, This has now been fixed in (pre-release) firmware for BT600 that I have verified. The expected schedule for a firmware release including this fix is at the end of August. Thanks, Lewis.

Mon, 05/11/2020 - 08:10

(Reply to #12) #13

tsicbergman

Lewis, that's great news. However, the end of August is a long ways off yet. Is there any way we could get access to v.1615 in the meantime?

Thu, 05/14/2020 - 03:23

(Reply to #13) #14

lcollins

Hi Caleb, It's not *recommended* to downgrade from v1723 to v1615, as this particular downgrade causes issue with future updates. I have sent you a direct message with more info. Thanks, Lewis.

Mon, 05/11/2020 - 08:11

(Reply to #14) #15

tsicbergman

(Ignore this; previous comment was posted twice)

Add new comment