947102 - [bluez]No Audio over BT headset for voice calls on JB builds

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Vendcom, defect)

Description

[bhargavg1]

See that on JB builds, there is no voice over BT headset when a call is established.

when setting up connection through [1] we only provide BLUETOOTH_HFP_STATUS_CHANGED_ID state which doesn't call SetForceForUse needed in JB builds [3] for correct routing of voice calls.
A check [4] is made later when trying to set the device strategy for a voice calls which we fail

Note we are using BlueZ stack

[1] http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluez/BluetoothHfpManager.cpp#1651
[2] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/AudioManager.cpp#251
[3] https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/audio/tree/alsa_sound/AudioPolicyManagerALSA.cpp?h=jb_3.2.1#n683
[4] https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/audio/tree/alsa_sound/AudioPolicyManagerALSA.cpp?h=jb_3.2.1#n1739

Comment 1

[Michael Vines [:m1] [:evilmachines]]

Shawn, who can look at this ASAP?

Comment 2

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I'm working with our audio guy (Star Cheng), we will update later.

Comment 3

[bhargavg1]

Folks seems to be an issue with specific headset, let me get back to you with more details

Sorry for the confusion

Comment 4

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

That makes sense, we tested with JB + bluedroid, and this part of code does not involve any stack part. And JB+ Bluedroid audio policy routing to SCO seems working fine.

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to bhargavg1 from comment #3)
> Folks seems to be an issue with specific headset, let me get back to you
> with more details
> 
> Sorry for the confusion
Thanks for clarification. If possible, and you provide hcidump during test and provide bluetooth headset model name?
We will check any potential SCO connection problem. It will be great if you can confirm SCO connection exactly connected.

Comment 6

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #5)
> (In reply to bhargavg1 from comment #3)
> > Folks seems to be an issue with specific headset, let me get back to you
> > with more details
> > 
> > Sorry for the confusion
> Thanks for clarification. If possible, and you provide hcidump during test
> and provide bluetooth headset model name?
> We will check any potential SCO connection problem. It will be great if you
> can confirm SCO connection exactly connected.

the one I am testing is, plantronics M1100 model. This used to work pretty much earlier. 

Can you let me know where can I find the hcidump tool

Comment 7

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

https://wiki.mozilla.org/B2G/Bluetooth#Helpful_Debugging_Information
hcidump shall be built if you use eng instead of userdebug.

Comment 8

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #7)
> https://wiki.mozilla.org/B2G/Bluetooth#Helpful_Debugging_Information
> hcidump shall be built if you use eng instead of userdebug.

Got the HCI dump and adb logs after enabling in UI. attached those.

STR:
Connect BT device
Make an MT call, ring is heard on the handset rather than the BT headset
Play an audio file, able to hear audio on BT headset
Disconnect BT headset

Comment 9

[bhargavg1]

Attachment: hci_data.zip

Comment 10

[bhargavg1]

Attachment: bt_adb.log

Received a call at, 02-20 23:34:15.760, in the log file

Comment 11

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to bhargavg1 from comment #9)
> Created attachment 8346345 [details]
> hci_data.zip
The log seems to be incomplete. Would you mind getting logs before connecting BT device (before STR step1)?

Comment 12

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi Joe,
We have QRD (8x26 platform), but we don't have the same source code to do further debug.
This bug can be reproduced on JB + BlueZ using plantronics M1100. Based on Comment 6, it works fine in previous build (I guess b2g 1.2 + ICS+BlueZ). I wonder if we can have the same environment to speed up the progress?

Comment 13

[Michael Vines [:m1] [:evilmachines]]

Working on this, stay tuned!

Comment 14

[bhargavg1]

Attachment: hci_v1.2.log

Comment 15

[bhargavg1]

Attachment: hci_v1.3.log

Comment 16

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #11)
> (In reply to bhargavg1 from comment #9)
> > Created attachment 8346345 [details]
> > hci_data.zip
> The log seems to be incomplete. Would you mind getting logs before
> connecting BT device (before STR step1)?

Attached logs from v1.3 and v1.2 with the same device. look for "PLT_M1100" in the logs.

The problem seems to be from the SDP reply. On 1.3 dont see a headset profile being returned but see for 1.2

Snippet from 1.2 log,

>>>
         record #2
              aid 0x0000 (SrvRecHndl)
                 uint 0x10002
              aid 0x0001 (SrvClassIDList)
                 < uuid-16 0x111e (Handsfree) uuid-16 0x1203 (Audio) >
              aid 0x0004 (ProtocolDescList)
                 < < uuid-16 0x0100 (L2CAP) > <
                 uuid-16 0x0003 (RFCOMM) uint 0x1 > >
              aid 0x0006 (LangBaseAttrIDList)
                 < uint 0x656e uint 0x6a uint 0x100 >
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x105 > >
              aid 0x0100 (SrvName)
                 str "Hands-Free unit"
              aid 0x0311 (SuppFeatures)
                 uint 0x19

<<<

Comment 17

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #11)
> (In reply to bhargavg1 from comment #9)
> > Created attachment 8346345 [details]
> > hci_data.zip
> The log seems to be incomplete. Would you mind getting logs before
> connecting BT device (before STR step1)?

Also the same device works with LA

Comment 18

[bhargavg1]

Will mark this as blocking for 1.3, as some of the headsets may not work correctly

Comment 19

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to bhargavg1 from comment #16)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #11)
> >>>
>          record #2
>               aid 0x0000 (SrvRecHndl)
>                  uint 0x10002
>               aid 0x0001 (SrvClassIDList)
>                  < uuid-16 0x111e (Handsfree) uuid-16 0x1203 (Audio) >
>               aid 0x0004 (ProtocolDescList)
>                  < < uuid-16 0x0100 (L2CAP) > <
>                  uuid-16 0x0003 (RFCOMM) uint 0x1 > >
>               aid 0x0006 (LangBaseAttrIDList)
>                  < uint 0x656e uint 0x6a uint 0x100 >
>               aid 0x0009 (BTProfileDescList)
>                  < < uuid-16 0x111e (Handsfree) uint 0x105 > >
>               aid 0x0100 (SrvName)
>                  str "Hands-Free unit"
>               aid 0x0311 (SuppFeatures)
>                  uint 0x19
> 
> <<<

This looks like SDP reply from the remote device (M1100) to controller, not from b2g.
In v1.3 log, i dno't see SDP query issued from controller. HFP seems not get connected. I don't even see any AT commands such as AT+BRSF

Comment 20

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

> This looks like SDP reply from the remote device (M1100) to controller, not
> from b2g.
> In v1.3 log, i dno't see SDP query issued from controller. HFP seems not get
> connected. I don't even see any AT commands such as AT+BRSF
Correct what I commented, AT commands were not been showed due to hcidump ascii mode was not been enabled.

Comment 21

[Joe Cheng [:jcheng] (please needinfo)]

still blocked with JB + BlueZ device. Any good news? Thanks

Comment 22

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I don't have M1100, but I tested Buri (1.3) with Plantronics Voyager Legend. It seems work fine. I will try to find one M1100 to test with.

Comment 23

[Michael Vines [:m1] [:evilmachines]]

(In reply to Joe Cheng [:jcheng] from comment #21)
> still blocked with JB + BlueZ device. Any good news? Thanks

Actively working on this but it will take time.  Probably not before the new year at this point unfortunately.

Comment 24

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #20)
> > This looks like SDP reply from the remote device (M1100) to controller, not
> > from b2g.
> > In v1.3 log, i dno't see SDP query issued from controller. HFP seems not get
> > connected. I don't even see any AT commands such as AT+BRSF
> Correct what I commented, AT commands were not been showed due to hcidump
> ascii mode was not been enabled.

this is the command I gave, hcidump --ascii -t 

Not sure why we dont see the command

Comment 25

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to bhargavg1 from comment #24)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #20)
> > > This looks like SDP reply from the remote device (M1100) to controller, not
> > > from b2g.
> > > In v1.3 log, i dno't see SDP query issued from controller. HFP seems not get
> > > connected. I don't even see any AT commands such as AT+BRSF
> > Correct what I commented, AT commands were not been showed due to hcidump
> > ascii mode was not been enabled.
> 
> this is the command I gave, hcidump --ascii -t 
> 
> Not sure why we dont see the command
If no AT command actually sent from headset, then I don't think things can really work normally. Except for M1100 headset, any other headset can hit this problem? This make me wonder we also need to check stack part. As I review your v.1.3 hcidump, only a few RFCOMM packets show up.
May I know the manfiest and bluez branch (includes bluez kernel part) currently use for test?

Comment 26

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I just checked the latest manifest. Maybe this is config.
<project name="platform/external/bluetooth/bluez" path="external/bluetooth/bluez" revision="f0689ac1914cdbc59e53bdc9edd9013dc157c299" upstream="b2g/jb_mr1_rb2.17"/>
<project name="kernel/msm" path="kernel" revision="acaf0fce57ce3a60cd0bda89e0923a92c4e1d688" upstream="b2g_jb_3.2">

Comment 27

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I checked again the log. And found something very strange.
In V1.3 log, SDP SSA Response, returned with two records. And they are actually duplicated.

2013-12-12 12:43:32.333677 > ACL data: handle 2 flags 0x02 dlen 24
    L2CAP(d): cid 0x0042 len 20 [psm 1]
        SDP SSA Req: tid 0x1 len 0xf
          pat uuid-32 0x111f (Handsfree AG)
          max 38
          aid(s) 0x0009 (BTProfileDescList)
          cont 00

2013-12-12 12:43:32.404748 < ACL data: handle 2 flags 0x00 dlen 44
    L2CAP(d): cid 0x0042 len 40 [psm 1]
        SDP SSA Rsp: tid 0x1 len 0x23
          count 32
------------------------------------>>>>>>
          record #0
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x106 > >
          record #1
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x106 > >
          cont 00

------------------------------------>>>>>>>

And in V 1.2 log, only one record returned, see below:

2013-12-12 13:01:37.891200 < ACL data: handle 4 flags 0x00 dlen 29
    L2CAP(d): cid 0x0043 len 25 [psm 1]
        SDP SSA Rsp: tid 0x1 len 0x14
          count 17
          record #0
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x105 > >
          cont 00

After this SDP SSA Response had done, AVDTP connection established. In V1.2, phone will receive the first AT command,
AT+BRSF, but in V1.3 log, no more RFCOMM packets sent from headset. Maybe strange SDP SSA Rsp make headset internal error. And SDP response is controlled by bluez stack. Bhargav, if you agree what I observed, can you help to clarify this part from stack level?

Comment 28

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #26)
> I just checked the latest manifest. Maybe this is config.
> <project name="platform/external/bluetooth/bluez"
> path="external/bluetooth/bluez"
> revision="f0689ac1914cdbc59e53bdc9edd9013dc157c299"
> upstream="b2g/jb_mr1_rb2.17"/>
> <project name="kernel/msm" path="kernel"
> revision="acaf0fce57ce3a60cd0bda89e0923a92c4e1d688" upstream="b2g_jb_3.2">

yes that is the configuration that's being used.

Comment 29

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

> After this SDP SSA Response had done, AVDTP connection established. In V1.2,
> phone will receive the first AT command,
> AT+BRSF, but in V1.3 log, no more RFCOMM packets sent from headset. Maybe
> strange SDP SSA Rsp make headset internal error. And SDP response is
> controlled by bluez stack. Bhargav, if you agree what I observed, can you
> help to clarify this part from stack level?
Any idea regarding SDP part based on Comment 27?

Comment 30

[Joe Cheng [:jcheng] (please needinfo)]

ping reporter again for comment 29 after the holidays

Comment 31

[bhargavg1]

I am checking with the BT team, shall update you soon

Comment 32

[Preeti Raghunath(:Preeti)]

Marco,

Can you please prioritize this blocker as it blocks QC CS?

The date for code drop is: 1/15/14.

Comment 33

[Marco Chen [:mchen]]

(In reply to Preeti Raghunath(:Preeti) from comment #32)
> Marco,
> 
> Can you please prioritize this blocker as it blocks QC CS?
> 
> The date for code drop is: 1/15/14.

Hi Preeti,

Shawn already watches this bug closely and refer to comment 29 & 31, we need feedback from partner.
By the way, there is no reference device for V1.3 + CAF BSP + BlueZ combination so we rely on partner's log or clues.

Comment 34

[bhargavg1]

Finally could figure out the issue. Seems to be an IOT issue.

On JB HFP version is updated to 1.6

----
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0106


While on ICS its updated to 1.5 
----
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0105

The headset is finding that to be strange.

Can I know where we update the version

Comment 35

[bhargavg1]

Complete sdp record

JB
--->
Service Name: Voice Gateway
Service RecHandle: 0x10005
Service Class ID List:
  "Handsfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0106
<---

ICS
--->
Service Name: Voice Gateway
Service RecHandle: 0x10008
Service Class ID List:
  "Handsfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0105

<---

Comment 36

[bhargavg1]

see that its being set at, 

https://www.codeaurora.org/cgit/quic/la/device/qcom/common/tree/rootdir/etc/init.qcom.bt.sh?h=b2g_jb_3.2#n151

Shawn can you share the out put the following commands from your device,

#adb shell getprop ro.bluetooth.hfp.ver
#adb shell getprop ro.board.platform

What is recommended HFP ver 1.5 or 1.6?

Comment 37

[Preeti Raghunath(:Preeti)]

Inder,

Can you please check if QC can test this internally?

Unable to test due to lack of ref devices.

Comment 38

[Inder]

Preeti, Bhargav is providing the test outputs for Shawn to analyze. Please let us know if any other information is needed. Also, we actively working on providing build for the reference devices you all received. Thanks.

Comment 39

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Bhargav, thanks a lot for your information. The getprop result is empty on Buri (v1.3 gecko + gaia).
I would recommend setting HFP version to 1.5 in init.qcom.bt.sh

Since v1.3 only implements HFP 1.6 mandatory AT command (AT+BIA), not support optional codec (mSBC) yet.

Comment 40

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

> The headset is finding that to be strange.
> 
> Can I know where we update the version

Base on my comment 27, sdp record is with duplicated records.
------------------------------------>>>>>>
          record #0
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x106 > >
          record #1
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x106 > >
          cont 00
------------------------------------>>>>>>>
Somehow, I still consider this part is strange. The BTProfileDescList attribute shall only contain one record, instead of duplicated attribute.

Comment 41

[bhargavg1]

(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #39)
> Bhargav, thanks a lot for your information. The getprop result is empty on
> Buri (v1.3 gecko + gaia).
> I would recommend setting HFP version to 1.5 in init.qcom.bt.sh

If no information is set, looks like we fall back to 1.5
https://www.codeaurora.org/cgit/quic/la/platform/external/bluetooth/bluez/tree/audio/manager.c?h=b2g/jb_mr1_rb2.17#n391 

> 
> Since v1.3 only implements HFP 1.6 mandatory AT command (AT+BIA), not
> support optional codec (mSBC) yet.

Comment 42

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Based on Comment 34, this bug is Bluetooth interoperability bug and I think I can not fix from Gecko internal. Will this still be 1.3 blocker?

Comment 43

[Michael Vines [:m1] [:evilmachines]]

Thanks a lot for the debug help here Shawn.   Yes, we need it fixed but looks like this'll be a Gonk fix so marking the bug as POVB.