I have tried a hangouts call using QC30 headset. The voice quality does drop when compared to a wired headset or when we speak with out any headset. 

The other person on the call also experiences bad audio quality when we use QC30 headset and select audio input to the bose headset.

QC35 seems fine.
We will find a QC30 to test.
Thanks for filing the bug!

Pramod, can we get couple more data points:
1. Try with non-Intel BT Chromebooks.  We could choose some or all of Miniie, Kevin & Dru to see if we see similar behavior.
2. Try with a MBP.

Jimmy, if you can't find a QC30 please let us know experiments we can run here to help provide more information.

Re #4

1.We tried the hangout call on kevin,dru and minnie using the QC30 headphones ( me using the QC30 and ruchi was on the other end using a wired headset, the voice quality dropped for me too , but it was audible.At the receiving end ( ruchi's end) audio quality was very poor ( hardly able to hear anything).

2.We tried the QC35 on these devices and could see that the audio quality on the receiving end was better compared to QC30 

3.We tried with mobile phone ( Pixel XL) with QC30 and same setup at ruchi's end and found that the audio quality is much better at both our setup's.

Dmitry, Joseph, Miao, can we tell what BT profile is being chosen on the Pixel XL vs on Chrome OS (I'm assuming it's going to be HFP for us)?

Re C#6: On chrome side, there seems no UI to determine which BT profile is being chosen. I do not find any way to show the information using bt-console either. If we open the debug option of bluetoothd/cras, we should be able to determine it. 

Re#6, yes we use HFP on ChromeOS when recording is in use.

Re#5
Finally I got the QC30. Joseph and I did the test today.

QC30 connected to Eve.
QC35 connected to Samus.

We found the sound quite clear on both end.

Could you get the audio recording dumps ?

a) open chrome://webrtc-internals in a separate tab 
b) select the current hangout call tab and enable the checkbox "Enable diagnostic audio recordings

You can refer to https://bugs.chromium.org/p/chromium/issues/detail?id=747450#c7


Thanks!

Hi Jimmy, 

Pramod and I reproduced the issue today. Here are the logs from my end (listening to Pramod, who was using the QC30. I was using wired headphones).

https://drive.google.com/open?id=1TUKB1MsRmXLFt_mKDzvKPBLbCRtkKd_n

Here are the logs from the eve machine which i was using with a QC30 headset connected. Ruchi was using wired earphones.I was able to hear ruchi's voice pretty well over the hangout call but ruchi was having problem with audio quality at her end.

https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/cr_843048/

I have uploaded the log to

https://webrtc-audiotools.googleplex.com/?meta=https%3A%2F%2Fwebrtc-audiotools.googleplex.com%2Faecdump%2FAMIfv95ZkceMTu8H4VWVUnMBcJUmB91rdXQCl4Oc1_NvygCUprn9GVav6ZvMnbT36t3ZhHOT0QvRyibXMbCsWghPtck1f6WzfEn7pxx3AsZ98y-jUn9t5oFtwBSA7UUUKn_V0yRRvXrVD0UeirWB8BLK5chr5nKFsJ11ssG1CXVMPajhAnUwPmYcidgn-b3_rY1BhT60xBsFMENv_rvChfISqAG-frwxocwlYRVZe-VGqAo-0E--SOSRnQOfcTvjGl0FF4DS-xR6MFjL_s2S0CTCflPfszqVL13p1mXLLNsGHvrvTNgYzLUMQlPf79Lbj-3iVU07HGKIWYJ-Rz9JMLiBdI0iGgQXv6foA5QXpdSW_0VGwkvk5zAOQKWSNovgW0MwMHbFM-XFwZV36YX4sqFyolWN3SHu5ieSoFJw_2EGWmdi_AnwYjO6SGwTUfEijMk1jTcSo58tehj3HL1jhwBybkoz3LHQqQ


The quality is about the same as the quality when I test it with Joseph.
I will let Hsinyu check whether this quality can be improved by adjusting any parameters.
At least, if we use it just like how Android does, we should get the same quality as Pixel 2 phone.

I was reporting the same issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=799623#c7

This is not a settings change. There is a bug in ChromeOS that randomly doubles the mic gain causing the captured audio to sound terrible.

The issue is that the microphone gain set to the bluetooth headset mic randomly and sporadically doubles. The audio gain is sometimes so high , it causes the audio captured to be distorted.

I tested this using multiple Bluetooth headsets on the PixelBookx and Samsung CB pro and Asus C101. All had this bug.

I used an app from the Play store that tests the audio gain input in a quiet room.
When the input gain works as expected from the Bluetooth headset, the gain app showed 30db. Randomly, when connecting a Bluetooth headset, the input would show 55+db in the same quiet room and when that happens, the audio captured from the headset sounds terrible.

I noticed this would randomly happen when i disconnect the BT headset and then reconnect it. This would also randomly happen after a CB restart and bluetooth device is reconnected.


Normally reconnecting the headset a few times or rebooting the device would bring the mic gain down back to normal.

You can use this app to test the sound level captured from the selected input device: https://play.google.com/store/apps/details?id=kr.sira.sound

1) Connect the BT headset and select the headset as the input source.
2) Open the sound meter app, see what the db level reads in a quiet room.
3) Close the app and make a test call. If the app showed around 30db in a quiet room, the audio captured on a call would sound great. If the app showed 55db+, the audio captured during the call will sound terrible and overblown.
4) reconnect the headset a few times / reboot the CB a few times so you can replicate the bug.

Thank you for the experiment, Jonathan!

You analysis reminds me of the optional supported AT+VGS/VGM commands for HFP. 
Chrome OS audio server sends AT+VGS command for speaker gain, but didn't issue any AT+VGM(for mic) command because Chromebook never sets microphone gain to audio peripherals.

The settings behavior is not defined in HFP/HSP. So the gain value on BT headset may go wrong just as what you observed.  A guess is that host side can do something to work around this problem.

Maybe we can always send a default 'mic gain' to bluetooth HFP headset, in the hope of force reset the randomly changing settings on headset. I'll give that a try and update on this issue.

@hychao

Thank you for looking into this. Hopefully your suggested solution would work and would set the audio input gain to a fixed correct level when using BT headsets.

Update:
Bad news: my guess in #14 does not help. 
QC30 reports supporting 'Remote volume control' but seems that doesn't cover capture gain. Use AT+VGM command doesn't change mic gain at all on QC30.

Good news: I've found out why the recording quality differs between Pixel phone and Pixelbook.

It's the 'wide band speech' feature supported on QC30, which can do higher quality on 16KHz using mSBC. Pixelphone supports this feature so user gets better recording.
Chrome OS only supports HFP 1.5 so HFP falls back to use the narrow band codec(CVSD) of lower quality audio.


https://stackoverflow.com/questions/27437907/difference-between-hfp-1-6-and-hfp-1-5

ChromeOS audio server implements the service level connection of the HFP, at
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/cras_hfp_ag_profile.c

There're a few things required for wide band speech support:

1. CRAS implements the AT+BCS/BAC commands for codec negotiation.
2. If headset supports mSBC codec (for wide band speech), CRAS should do the audio data encoding/decoding.
3. Qualify Chrome OS for higher version of HFP (1.6 or 1.7).


Just did an experiment, I can get the codec list report from QC30 through AT+BAC command, even when service record sticks to HFP 1.5.
So I guess some headsets would have wide band speech working even ChromeOS side claiming HFP 1.5 support. 

I suggest we start by the implementation (1), (2) listed above, and see how the new headsets(need to test more headsets in addition to QC30) work on ChromeOS.
If we found any headset that requires ChromeOS to claim HFP > 1.5 support in order to switch to wide band mode, then we can think about qualification.

Sameer, Dmitry:
Does the plan sound okay to you?


Changing this to P2 since this is a new feature not regression.

I have been told by local techstop that the Google provided BT headset have the same issue: https://mystuff.corp.google.com/stuff/items/1699

I also want to make clear that the bad audio quality is on the QC30 end, I'd think it's unrelated to the microphone gain. When switching to QC30 mic input, the audio output quality in the QC30 headset becomes very poor.

Re #19:
Yes the quality of both playback and recording are poor when QC30 uses the narrow band codec.
Once the support to wide band speech is implemented, Chromebook + QC30 should have good quality audio on both directions, just like Pixel phone.

Do we know how many headphones are getting effected due to the lack of this support? If this is becoming prevalent in use, P2 seems a bit low.

c#18: plan sounds good in general. Please suggest a target milestone.

It seems hard to know whether a headset supports wide band speech :(
For example when I searched QC30 on https://launchstudio.bluetooth.com/Listings/Search
and look up the ICS details for HFP, it shows non-support wide band speech and mSBC codec, but in fact QC30 supports this.

I'd guess new + premium headsets like QC35/QC30 all have this support. (just tested Plantronics voyager Edge doesn't support wide band speech.)

Let's try target M69.

69 sounds great, thanks Hsin-yu!

Not going to make it in M69, moving to M70.

Ping!! Any update on this issue?

FYI, This happens with pixel buds and Foxconn GID6B (Google ODM model) not just the Bose QC30

Has started implementation of this.
Not going to make M72, aim for M73 instead.

Will add in more info when I have progress.