search

mumble-voip / mumble-iphoneos

Mumble client for iOS-based devices
https://www.mumble.info
Other
196 stars 78 forks source link

mic input very poor on bluetooth #125

Open StanleyTHChow opened 5 years ago

StanleyTHChow commented 5 years ago

I just started to use mumble, on iOS 12.2 on iPhone 6S plus and iPhone 6, any bluetooth earbuds; the mic input is very choppy. I tried all settings under VOX, very little changes. With wired earbuds, everything is great.

Under Plumble on Android 4.2.1 on Nexus 4, both wired and bluetooth work at default settings.

Under mumblefy (on iOS 12.2), both wired and bluetooth work at default settings.

trevorirwin commented 4 years ago

Hi, I did some digging into this and I believe I've identified the root of this issue! It appears to be a sample rate problem.

I found another project called Audio Kit where people were experiencing similar symptoms, and it turned out that a system call was giving them an incorrect sample rate for the microphone only, causing an improperly sized buffer to be generated and creating the choppy audio also experienced by Mumble for iOS users.

I pulled down the Mumble for iOS source code and started experimenting. I found that the problem is resolved if you enter the MumbleKit source and modify line 13 of MKAudio.h to use a lower sample rate, e.g.:

#define SAMPLE_RATE 16000

Now, I don't know that much about this codebase, or iOS programming at all for that matter. But I noticed that in MKAudio.m there is a method that sets the preferred hardware sample rate at line 203 that includes a comment:

The AudioSession can reject this, in which case we need to be able to handle whatever input sampling rate is chosen for us.

My guess as to the actual root cause of the problem is that the Bluetooth headsets experiencing this choppy audio problem are headsets where the maximum input sample rate is lower than the maximum output sample rate. Looking through other areas of the source, MumbleKit seems to always assume they are the same. By setting a lower "preferred" sample rate that both input and output are compatible with, the issue is resolved.

The long term solution is to update the entire codebase to appropriately handle disparate input/output sample rates.

As a short term solution, a switch could be added to the Preferences/Advanced menu called "Bluetooth compatibility mode", which would force a common lower sample rate like 16000.

@mkrautz : I would do either of these myself and submit a Pull Request, but I have very little experience with Objective C and iOS, so I'm not sure my code would be up to snuff and it would take me a very long time. Is this something you might have the bandwidth for, or should I try my best and submit a PR?