Unstable audio connection when using a Bluetooth headset with NVDA

[LeonarddeR]

Steps to reproduce:

1. Connect a Bluetooth Headset with your pc. I used a Plantronix M70
2. Interact with the system with NVDA running.

Expected behavior:

Output from NVDA to the headset is continuous, i.e. it is not interrupted at random moments. It does not make any difference for the connection stability whether you have music playing in the background or not.

Actual behavior:

Once in a while, speech output is lost for around three seconds. When music is playing in the background, these drop outs do not occur.

Additional details

• This issue does not occur with JAWS. However, it does occur with Narrator. Therefore I assume it has to do with the way NVDA and Narrator deal with audio (i.e. whether they leave the device open after outputting something)
• This is most likely related to #5172. The reason why I opened a different issue is that, while the other issue talks about performance loss, this issue has to deal with real loss of audio output. Furthermore, this issue is specifically related to Bluetooth audio. See also https://github.com/nvaccess/nvda/issues/5172#issuecomment-155340759 . It looks like the workaround provided by @jcsteh does not apply here.
• See also #5096,

System configuration:

NVDA version: next-14869,61ec7e91 NVDA Installed Windows version: Windows 10 Fall Creators update, build 16299.248

Other questions:

Does the issue still occur after restarting your PC? Yes

Have you tried any other versions of NVDA? No

[Adriani90]

I have the same Problem on Dell xps13 and on my work Station. But in my case Jaws has the same Problem. I have found a viable solution as follows:

1. Create a short 16 bit 11 khz mono wav file with very low frequency (10 hz) and fade in and out to avoid clicking

Then a vb script like this:

Set Sound = CreateObject("WMPlayer.OCX.7")
Sound.URL = "WakeupHum.wav"
Sound.Controls.play
do while Sound.currentmedia.duration = 0
wscript.sleep 100
loop
wscript.sleep (int(Sound.currentmedia.duration)+1)*1000

Windows Scheduler Plays it every 3 seconds. I run this script as .vbs with wscript.exe.

Actually this one could be integrated into NVDA's core since the user would not notice it at all.

You can find the discussion on this Website: http://www.tomsguide.com/answers/id-2417519/prevent-speaker-standby-mode.html

[zersiax]

Other headsets deal with this even less gracefully, various Plantronics Backbeat versions actually start stuttering when they re-establish the hold on the audio device, requiring you to power-cycle the headset before normal operation resumes. As stated, this does not happen if other, constant audio like background music is playing, or if some other process is holding the audio device open. What I tend to use for this is Blindspot, which seems to keep the audio device open forcefully after starting playback and pausing. That is more than likely a bug, but it works well to patch this particular issue.

[Adriani90]

@mltony created an add-on which solves this issue.

[Adriani90]

This issue might probably be fixed by #11024. I think the discussion can be continued there or on #5172. I am closing this for now.

[jage9]

Coming back to this issue. The fix that was applied for sound cards does not specifically help with Bluetooth audio. There is a current add-on, but I would propose its major functionality becomes added to core, as Bluetooth headsets are now quite common and this is a common complaint for users. JAWS has this built-in for comparison. Can start a new issue if desired.

[seanbudd]

@jage9 - Before I reopen the issue, is the current issue description accurate? What would be your proposal?

[jage9]

@seanbudd yes the original description still applies, with some notes:

• There is a setting in JAWS which corrects this behavior
• The Bluetooth Audio add-on for NVDA currently also solves the issue. Given the prominence of this issue, I'm recommending this get merged into core in some fashion. @mltony wrote the add-on. Do you have any thoughts?

[mltony]

That would make sense to me. I am quite busy these days, but I can probably find some time to prepare a PR towards the end of the year - as long as nvaccess is willing to merge it. Or alternatively, I have no problems if nvaccess or anyone else wants to prepare PR. One thing to be aware of: current version of bluetooth audio doesn't respect when user changes output device in NVDA (or rather restarting NVDA required). And many users are confused by this. This should be probably fixed before merging into core.

[Adriani90]

@leonardder how is this now in last NVDA alpha using WASAPI?

[bhavyashah]

Two remarks (with utmost respect):

• IMHO, It is a bit disrespectful to leave comments like https://github.com/nvaccess/nvda/issues/8017#issuecomment-892257161 unresponded for years. I think an open-source project that values community contributions ought to be more responsive to offers of code contributions. Of course, if the comment - specifically, its question about whether a PR would be accepted by NV Access - just got missed in all the NVDA GitHub activity, that's more understandable.
• This is a perfect example of an issue that really should have been addressed in core a while ago but has needed to be handled by the add-ons community over the years (Bluetooth Audio, White Noise, and possibly others). Bluetooth-based audio output devices are used very widely today, and speech is the modality of a screen reader for most users. I remember a time when I experienced speech cutoffs with my Bluetooth headphones, and remember how poor the experience was then. Please consider prioritizing this ticket.

[jcsteh]

* IMHO, It is a bit disrespectful to leave comments like [Unstable audio connection when using a Bluetooth headset with NVDA #8017 (comment)](https://github.com/nvaccess/nvda/issues/8017#issuecomment-892257161) unresponded for years. I think an open-source project that values community contributions ought to be more responsive to offers of code contributions.

The comment you reference asks no questions that need a response. Contributors are always welcome to submit pull requests, and it is pretty clear these days that pull requests from contributors frequently get merged. This issue hasn't been closed and has in fact been triaged with a priority, which means it is open for the taking.

Of course, if the comment - specifically, its question about whether a PR would be accepted by NV Access - just got missed in all the NVDA GitHub activity, that's more understandable.

That is also fairly likely.

* This is a perfect example of an issue that really should have been addressed in core a while ago but has needed to be handled by the add-ons community over the years (Bluetooth Audio, White Noise, and possibly others).

As you are no doubt aware, there are many more considerations and consequences for a feature going into core than there are in an add-on. Aside from the risk of regressions impacting many more users than an add-on might, there are many other things that don't need to be quite as well considered or polished in an add-on as they do in core. Also, anything that goes into core has to be maintained for the long-term. And this isn't even getting into the priority of this relative to everything else.

[jcsteh]

Could anyone impacted by this please test this try build? The silence isn't configurable at the moment and is currently hard-coded to 30 seconds after the last audio played. The underlying code does support an adjustable duration; I just don't have the time to write the config code right now. Anyway, it'd be good to prove whether this works before putting any more work into it.

[bhavyashah]

Works as intended for me. With NVDA 2023.3 (all add-ons disabled), after 15 seconds of inactivity, I experience a speech cutoff through my headphones when I issue a command on my computer. With the try build though, that goes away. Thanks!

[Adriani90]

I found this discussion https://forum.audiogames.net/topic/50308/nvda-cutting-out-when-on-battery/ which suggests that changing the priority to "high" for the Windows Audio Device Graph Isolation process (audiodg.exe) in the Windows task manager solves these cut off speech issues.

Look for comment 7 in that discussion.

Jamie it seems your prototype with the silence works as well, but maybe tweaking the process running priority when NVDA starts could also be an option. However I am not sure if this can be done for specific event only (i.e. only when the synthesizer is speaking).

[Adriani90]

@LeonarddeR, @zersiax, @jage9 are you still having this issue with NVDA last alpha version? I think #16147 and #16099 have brought a positive effect on this.