search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.39k stars 1.12k forks source link

Poor quality audio when using bluetooth headphones #3491

Closed jackys-95 closed 2 years ago

jackys-95 commented 6 years ago

I have noticed a strange system wide audio bug when using Mumble with bluetooth headphones. The moment I start Mumble system wide audio reduces in quality drastically e.g. intermittent cutting out, added crackle noise. Normal audio quality resumes when I close Mumble. I am currently using Mumble 1.2.19 on Mac OS High Sierra (10.13.6) with a pair of BeatsX headphones on a MacBook Pro 2018. A friend of mine has reproduced this issue on a MacBook Pro 2015 with a pair of Bose QC35.

davidebeatrici commented 6 years ago

Could you try to install the latest snapshot and check if the issue persists, please?

jackys-95 commented 6 years ago

Ive just tried a snapshot (Mumble-1.3.0\~2729\~g2126495\~snapshot.dmg) and the issue is still present.

davidebeatrici commented 6 years ago

Does the issue persist if you unplug the headphones?

jackys-95 commented 6 years ago

Upon disconnecting the bluetooth headphones, the audio sounds perfectly normal using the speakers.

jeto commented 6 years ago

Have you tried switching the microphone input from the headphones to internal?

https://superuser.com/questions/12292/bluetooth-headphones-sound-terrible-on-mac-os-x

adiq commented 5 years ago

Switching mic to other input works great, but it still seems like a temporary fix.

reinoud-jules commented 4 years ago

Late to the party, but this has to do with a limitation of the Bluetooth protocol. To allocate for data being sent and received (mic data transmitted, and audio data received), the Bluetooth protocol lowers its quality drastically to save bandwidth. I have been struggling with this for ages, and even bought new headphones only to find out it has nothing to do with the headphones, or macOS in particular.

adiq commented 4 years ago

@reinoud-jules as far as I remember Google ~Hangouts~ Meet or Discord works fine, so I would be skeptical about Bluetooth protocol limitations.

reinoud-jules commented 4 years ago

With Apple Airpods Pro I have the same problem with hangouts, discord, and VoIP calling. When, in those apps, I switch the input source (microphone) to the default source (iMac or MacBook Air), the audio quality is unchanged. As soon as I change the input source to the AirPods mic, the audio becomes low quality. This is, of course, anecdotal evidence, but I read somewhere else that this was due to the limitations of Bluetooth, which I found to be plausible.

mabbamOG commented 4 years ago

Just tried out with both Mumble and Discord. The audio quality is reduced as soon as audio transmission begins.... so it seems to be an issue inherent with either the bloetooth protocol or the headphones.

Anyway, if the devs can't manage to fix this with code, a simple "fix" is to just setup a warning text when the app detects bluetooth headphones. The user can then just jump to audio input and switch it to laptop

Krzmbrzl commented 4 years ago

@mabbamOG so you expierenced this problem with both Mumble and Discord separately (that is by their own respectively. Not just when running both or something like this)?

a simple "fix" is to just setup a warning text when the app detects bluetooth headphones

I'm not sure we can actually determine whether a headphone is using Bluetooth or not...

ghost commented 4 years ago

It's limitation of bluetooth HSP/HFP protocol. If headset doesn't use microphone, it's set to A2DP profile, which may use various low latency, high quality codecs. If microphone is in use, it's switched to low bandwidth HSP/HFP mode, so audio playback is limited to 64 kbit/s 8kHz CVSD voice coding or 16kHz mSbc codec. It looks like it's possible to use QT 5.6 to detect headset using "Bluetooth LE Central" on all major platforms - https://doc.qt.io/qt-5/qtbluetooth-index.html

Krzmbrzl commented 4 years ago

Thanks for the hint @Reikion! :)

If someone wants to give this a shot, a or would be very welcome. Don't know if and when I'll have time to look into this...

Krzmbrzl commented 2 years ago

As I don't think that a feature like this is easily integrated into the current audio system, we'll use https://github.com/mumble-voip/mumble/issues/5408 to track it instead.

mirh commented 2 years ago

Idk really how the application layer could control the driver/protocol layer. Maybe you could detect the situation (and maybe inform the user, since this appears a frequent nuisance), but if HFP sucks you can't do much without the OS and hardware cooperating at least.

Krzmbrzl commented 2 years ago

I'm not even sure if detecting whether the current microphone is using Bluetooth is easy :thinking:

I also think that there is only so much we can do about this though. However in the linked issue, there are also requests to e.g. close the input device while the user is e.g. self-muted at which point the OS might switch the profile back to something with better quality. Maybe something like that might at least help a bit. :shrug:

mirh commented 2 years ago

That could make sense I guess, even though profile switching can take some seconds and the user is on their own there if that's still a good thing or not. (especially on linux perhaps, where supposedly you can force wideband codecs even for HFP shit)