Closed Bug 883619 Opened 7 years ago Closed 7 years ago

[Bluetooth] No busy tone on Car kit

Categories

(Firefox OS Graveyard :: Bluetooth, defect, major)

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(blocking-b2g:leo+, firefox22 wontfix, firefox23 wontfix, firefox24 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd fixed)

RESOLVED FIXED
1.1 QE3 (26jun)
blocking-b2g leo+
Tracking Status
firefox22 --- wontfix
firefox23 --- wontfix
firefox24 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix
b2g-v1.1hd --- fixed

People

(Reporter: leo.bugzilla.gecko, Assigned: ben.tian)

References

Details

(Whiteboard: [fixed-in-birch])

Attachments

(3 files, 2 obsolete files)

GENERAL Defect Description 

1. Precondition : DUT and CK are connected
2. Tester's Action : Make an outgoing MO call to external line which is actually busy
3. Detailed Symptom : there is no busy tone on Car kit
4. Expected : Should be hear able three short tones

Busy tone is depend on network.
If network support the busy tone, it is heard busy sound about 2~3 times and then b2g phone generate busy sound about 2~3 times. So total 5~6 times.
But if it does not support busy tone, only b2g phone generate busy sound about 2~3 times.

In this state, b2g phone connect with carkit via bluetooth and reproduce this case.
Then busy tone is heard via bluetooth about 2~3 times but since then busy tone is heard via phone receiver about 2~3 times.
And if network does not support busy tone, there is no busy sound via bluetooth.

The cause of this problem seems to be due to the sound path.

06-11 08:42:56.271 -*- RILContentHelper: Received message 'RIL:CallStateChanged': {"state":1,"callIndex":1 ..
06-11 08:42:56.271 HandleCallStateChanged:1323 [LGBT_gecko] aCallIndex = 1, aCallState = 1, aSend = 1
06-11 08:42:56.781 Bluetooth sco status changed..
06-11 08:42:56.781 setDeviceConnectionState() device: 20, state 1, address 00:0E:9F:C8:2A:B9

06-11 08:42:58.991 -*- RILContentHelper: Received message 'RIL:CallStateChanged': {"state":3,"callIndex":1 ..
06-11 08:42:58.991 HandleCallStateChanged:1323 [LGBT_gecko] aCallIndex = 1, aCallState = 3, aSend = 1

06-11 08:42:58.991 -*- RILContentHelper: Received message 'RIL:CallStateChanged': {"state":10,"callIndex":1 ..
06-11 08:42:58.991 HandleCallStateChanged:1323 [LGBT_gecko] aCallIndex = 1, aCallState = 10, aSend = 1
06-11 08:42:59.001 Bluetooth sco status changed..
06-11 08:42:59.001 setDeviceConnectionState() device: 20, state 0, address 
06-11 08:42:59.001 setDeviceConnectionState() disconnecting device 20

06-11 08:42:59.801 out Routing audio to speaker... (Ring the generated busy tone by b2g phone)
06-11 08:43:00.641 out Routing audio to speaker... 
06-11 08:43:01.441 out Routing audio to speaker...
06-11 08:43:02.361 out Routing audio to speaker...
06-11 08:43:03.431 out Routing audio to speaker...

When call state is changed to 10(disconnect) from 3(busy), bluetooth sco is disconnected and then ring the generated busy tone via phone receiver by b2g phone.

Likewise, the process to change the sound path should be checked again.
Please review this process.

Thanks.
blocking-b2g: --- → leo+
Attached file No_busy_tone_log
Target Milestone: --- → 1.1 QE3 (24jun)
It seems we need to keep bluetooth SCO status on when b2g device wants to play the busy tone.
See Also: → 857951, 881142
Attached patch Keep Sco until busy tone ends (obsolete) — Splinter Review
The patch defers Sco disconnection after busy tone ends. I've verified on the handset and carkit we have.

leo, can you try if this patch works on your carkit?
Attachment #764653 - Flags: review?(echou)
Flags: needinfo?(leo.bugzilla.gecko)
I have tested busy tone and it is working well.
Thanks for your help.
Flags: needinfo?(leo.bugzilla.gecko)
Comment on attachment 764653 [details] [diff] [review]
Keep Sco until busy tone ends

Review of attachment 764653 [details] [diff] [review]:
-----------------------------------------------------------------

ok, overall looks good, but several things need to be revised.

Since Ben will be out of office for a week, I'll take over.

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +60,5 @@
>    // magic number. The mechanism should be revised once we can get call history.
>    static int sWaitingForDialingInterval = 2000; //unit: ms
> +
> +  // Busy tone related
> +  static bool sCloseScoLaterFlag = false;

We don't really need this variable since it's ok if we call DisconnectSco when sco socket doesn't exist.

@@ +1428,5 @@
>        // -1 is necessary because call 0 is an invalid (padding) call object.
>        if (mCurrentCallArray.Length() - 1 ==
>              GetNumberOfCalls(nsIRadioInterfaceLayer::CALL_STATE_DISCONNECTED)) {
>          // There is no call, close Sco and clear mCurrentCallArray
> +        if (prevCallState != nsIRadioInterfaceLayer::CALL_STATE_BUSY) {

nsITelephonyProvider should be used for m-c.
Attachment #764653 - Flags: review?(echou)
* updated
Attachment #765292 - Attachment is obsolete: true
Attachment #765292 - Flags: review?(gyeh)
Attachment #765769 - Flags: review?(gyeh)
Comment on attachment 765769 [details] [diff] [review]
patch 1: v2: postpone the timing of dropping SCO if the line is busy

Review of attachment 765769 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +1708,4 @@
>      NS_WARNING("BluetoothHfpManager is not connected");
>      return false;
>    }
>  

We could store the value of |mScoSocket->GetConnectionStatus()| in a variable and reuse it in the if-condition.
Attachment #765769 - Flags: review?(gyeh) → review+
nit picked.

birch: https://hg.mozilla.org/projects/birch/rev/1578c05bb33f
Whiteboard: [fixed-in-birch]
* b2g18-specific patch
https://hg.mozilla.org/mozilla-central/rev/1578c05bb33f
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.