Description
On the latest release of the Electron SDK, I’m attempting to disable the Push to Talk / Hold Space Key To Speak feature through the exposed Audio Setting. It is set to True by default. If I set it to False, the setting is still enabled. If I call isHoldSpaceKeyToSpeakEnabled, it returns False if I’ve set the setting to false, but the setting is still enabled in the audio settings UI panel and the feature is still active.
Setting bEnable to False does not disable the feature. The screenshot below shows that the feature is still enabled despite calling the SDK function linked above with a False parameter to disable it.
In contrast, I was able to successfully toggle the setting for the Always Mute Mic When Join Voip setting:
The default value for that setting is False, and when I set to True, the change was accurately reflected in the audio settings as shown in the screenshot below.
To Reproduce(If applicable)
Steps to reproduce the behavior:
Start a meeting using the electron SDK without changing Audio Settings and observe that the Hold Space Key To Speak feature in Audio Settings panel is enabled
Disable the Hold Space Key To Speak feature using the SDK function linked above in the Electron SDK
Check the audio settings and attempt to use the Hold Space Key To Speak feature
Result: The setting is still enabled despite disabling it using the SDK function and the feature is still available
Screenshots
The following screenshot shows that the feature is still enabled, although I’ve called Setting_EnableHoldSpaceKeyToSpeak with a false parameter:
Additional context
My Electron app has a text editor component, and when users type space bar, there is very significant lag induced by the Push to Talk feature which causes disruption to the inputted text. So I would like to disable the feature by default to prevent the lag.
If it helps - looks like this is an issue at the native macos zoom framework layer. I pulled the sample macos sdk and attempted to disable the PushToTalk feature using:
ZoomSDKAudioSetting* audioSetting = [[[ZoomSDK sharedSDK] getSettingService] getAudioSetting];
ZoomSDKError result = [audioSetting enablePushToTalk:NO];
Result was ZoomSDKError_success but the feature was still enabled and working on the running app. I haven’t tried this on Windows so not sure if it is working for the Windows native framework.
Thank you very much for the info, really appreciate it. I have forwarded this to the engineering team for further investigation. Will get back to you shortly.
Thanks Carson! Some additional context that may or may not be valuable for the engineering team - I’ve been doing some digging on why this push to speak feature would cause lag on my own component, and it looks like something like this is happening (I don’t have access to Zoom macos source code so I can only speculate):
This event monitor checks the timing of the space key keydown event to see whether the key is held down so it can decide whether push to speak should be triggered
It appears that the above is a blocking handler, so the keydown event will not be sent to my application window until the Zoom event monitor handler has deemed it is not a hold-down event, despite my window being both the key window and first in the responder chain
In the meantime, non space bar keydown events will not be blocked by the event monitor and those are sent to my window correctly
To reiterate the impact, this functionality does have significant side effects to my text editor component in my application for end users. For example, entering a string such as “Hello world my name is foo” will consistently result in outputs like “Hellow orldm yn amei sf oo” while muted since the keydown event for Space key is processed slightly after the following keydown event.
If my above theory is accurate, I’m having difficulty understanding how to seamlessly work around it on our end since I would like to avoid asking asking our users to manually disable the push to speak feature. Since we don’t have access to the event monitor handler object, we cannot remove it as a listener. Adding our own local event monitor to handle the space key does not always take precedence over the one in Zoom library.
One option I have found is to subclass NSApplication and take control of the sendEvent processing loop so we can send space key events to our window before it is sent to local event monitors for processing. This is easy enough on the macos sdk runtime but unfortunately we’re using the Electron SDK where it seems less trivial to subclass the AtomApplication without significant modification to underlying libraries.
Again this is all speculation since I can’t say for sure without inspecting zoom framework source, but based on some experimentation it appears to be what’s happening under the hood. Would love to hear some thoughts on this to see if there are any other options and/or if I’m missing something obvious.
Wow, thank you very much for the detailed information. Our engineering team is able to identify a bug based on the information provided and we will fix this in the next release. Pardon the inconvenience caused by this.
Our engineering team is able to identify a bug based on the information provided and we will fix this in the next release. Pardon the inconvenience caused by this.