Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA stops responding when a bluetooth audio device is connected to the computer #4178

Closed
nvaccessAuto opened this issue Jun 8, 2014 · 7 comments

Comments

@nvaccessAuto
Copy link

Reported by k_kolev1985 on 2014-06-08 11:06
'''Description:'''
Until recently, I was using the TOSHIBA Bluetooth Stack for my bluetooth needs (mainly for connecting my bluetooth headset and sending files to my tablet and my phone). When connecting my bluetooth headset to my computer, it was a little tricky, but not impossible, to make NVDA send its audio output to the bluetooth headset (no matter if via the A2DP or the HFP (hands-free) protocols). That - using the TOSHIBA Bluetooth Stack software.

Yesterday I've decided that the TOSHIBA Bluetooth Stack software was too heavy and too bloated for my needs and taste. So, I've uninstalled it and started using the built-in Bluetooth functionality of Windows itself. It's not bad, except for the too long automatically generated PIN codes for pairing, but I can live with that.

I've noticed however, that if the bluetooth headset is connected to the computer via both the A2DP and HFP protocols and the HFP protocol kicks in (it does specially when on a Skype call via the Skype app for Windows 8 and when in the "recording" tab of the "Sound" in the Control Panel), NVDA will stop responding: no sound comes from it and the NVDA commands stop working. As soon as the headset switches back to the A2DP protocol, NVDA starts working normally again.

I've set NVDA's logging level to "Input/Output", reproduced the issue and I'm attaching here the log file witch should hopefully contain some useful information about what's going on.

'''NOTES:'''

  1. In order for the system to know when to switch to the HFP protocol, the HFP (headset) mode of the bluetooth headset is set as a default communication device in Control Panel -> Sound. The A2DP (headphones) mode is set as a default audio device in Control Panel -> Sound. Both modes appear as separate audio devices in Control Panel -> Sound.
  2. Same happens with Narrator. Can't tell for other screen readers, because I don't have any of them installed.
  3. The issue with NVDA occurs no matter if the output device set in the NVDA's "Synthesizer" dialog is set to the Microsoft Sound Mapper or my sound card.
  4. The issue with NVDA occurs no matter if a SAPI5 synthesizer is used or the built-in eSpeak.

'''Steps to reproduce it:'''

  1. Install a bluetooth headset with both A2DP and HFP protocols supported.
  2. Connect it to the computer via both protocols (it's done via the "Connect" context menu command for each bluetooth playback audio device in Control Panel -> Sound). NVDA will start talking via the A2DP protocol.
  3. While you're still in the "Sound" dialog, switch to the "Recording" tab. The HFP protocol will kick in. NVDA will stop talking and will not respond to commands.
  4. Go to the "Playback" tab again. NVDA will resume speaking and will respond to commands again.

'''Actual results:''' When the HFP protocol is the active one, NVDA stops talking and will not respond to commands.

'''Expected results:''' NVDA should be able to work even if the HFP protocol is active and use that audio for speech output. I think NVDA would work normally if it "knows" to automatically switch its speech output to the "Headset" audio device, but it doesn't. And since it doesn't respond to commands, we can't switch the speech output device manually either. Actually, it seams that screen readers like NVDA and Narrator don't know how to output their speech to the default communication device and that is why they react like that in a situation like that. Though I might be wrong.

'''Test environment:'''

  • Operating system: Windows 8.1 Pro N, 64-bit, with all updates installed.
  • NVDA versions: next-10673,1813d27; 2014.2.
  • Sound card: Realtek ALC888 with the latest drivers installed.
@nvaccessAuto
Copy link
Author

Attachment NVDA_Log_2014-06-08.log added by k_kolev1985 on 2014-06-08 11:07
Description:

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2014-06-09 04:46
To clarify one comment:

The issue with NVDA occurs no matter if the output device set in the NVDA's "Synthesizer" dialog is set to the Microsoft Sound Mapper or my sound card.

I assume you mean the Bluetooth headset, not your system sound card? I assume this issue does not occur if you set NVDA to use your system sound card?

Can you set NVDA to use the HFP output instead of the A2DP output? If so, what happens if you do this?

My suspicion is that when the headset/driver switches to HFP, the A2DP output freezes, even though it still remains active according to the system. Windows probably doesn't report that the default playback device has changed, so NVDA continues to try to use the A2DP output. If you're, say, playing music when you switch to the Recording tab, does it too stop playing until you switch back to the Playback tab? What happens to system sounds once you switch to the Recording tab?

I'm not sure there's anything we can do about this. An audio output shouldn't ever freeze like that. That seems like a pretty serious bug in the driver.

@nvaccessAuto
Copy link
Author

Comment 2 by k_kolev1985 (in reply to comment 1) on 2014-06-09 08:17
Replying to jteh:

To clarify one comment:

The issue with NVDA occurs no matter if the output device set in the NVDA's "Synthesizer" dialog is set to the Microsoft Sound Mapper or my sound card.

I assume you mean the Bluetooth headset, not your system sound card? I assume this issue does not occur if you set NVDA to use your system sound card?

Actually, when I wrote about setting the output device and when testing, I meant doing it before I connect the bluetooth headset to the computer and not after that. If I switch NVDA to use the sound card after connecting the headset, the freeze doesn't occur, because NVDA uses the sound card output (my analog speakers) and not the headset.

Can you set NVDA to use the HFP output instead of the A2DP output? If so, what happens if you do this?

Yes, after connecting the bluetooth headset to the computer, I can set NVDA to use the HFP output instead of the A2DP one. In this case, every time NVDA speaks, the driver switches the audio output to the HFP one, interrupting (pausing) so the sounds (incl. music playback) played via the A2DP output. As soon as NVDA stops speaking, the driver reverts the audio output to the A2DP one.

If you're, say, playing music when you switch to the Recording tab, does it too stop playing until you switch back to the Playback tab? What happens to system sounds once you switch to the Recording tab?

If I switch to the recording tab (switch the output to the HFP one) while playing music, the music playback gets paused until switch to the A2DP output again. I think the same happens to the system sounds as well (at least as far as I could test).

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2014-06-09 08:33
That would suggest my suspicion is correct: the two profiles can't be used simultaneously. It would probably make sense for Windows to report a switch in default playback device when HFP is engaged, rather than just freezing A2DP output, but from what you're saying, it doesn't seem to do this.

Leaving open because I don't have such a device and can't test this. Hopefully, someone who has one can come up with a work around, but unfortunately, I very much doubt it.

@bhavyashah
Copy link

@jcsteh's #4178 (comment) implies that someone with such a device would be in a position to investigate this bug further. Clearly, no one has stepped up with necessary prerequisites in the past three years. Additionally, Jamie very much doubts that a work-around for an issue of this kind even exists. If @k_kolev1985 does not disagree, I suggest closing as cantfix. @ehollig

@k-kolev1985
Copy link

k-kolev1985 commented Aug 27, 2017

Since this is not a bug in NVDA itself and a workaround from NVDA is probably not possible, I agree that the issue should be closed. I've sent a feedback to Microsoft about this via the Feedback Hub, which can be found here: https://aka.ms/bknmwh. I don't know if that way the issue will get to the right people at Microsoft and if they will do something about the issue, but that is the only way that I know of to report bugs to Microsoft. Well, actually, there is another way via some sort of forums for reporting bugs and sending ideas and I might use that channel as well. 😀

@ehollig
Copy link
Collaborator

ehollig commented Aug 27, 2017

As this is not an issue with NVDA and an appropriate bug has been filed with Microsoft, closing as requested in #4178 (comment)

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

No branches or pull requests

4 participants