A2DP streaming takes more than 15 seconds to resume after SCO connection is terminated.

RESOLVED DUPLICATE of bug 961986

Status

Firefox OS
AudioChannel
P1
critical
RESOLVED DUPLICATE of bug 961986
4 years ago
4 years ago

People

(Reporter: Greg Grisco, Assigned: squib)

Tracking

(Blocks: 1 bug, {regression})

unspecified
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.3+, b2g-v1.3 affected)

Details

(Whiteboard: [caf priority: p1][CR 595623])

(Reporter)

Description

4 years ago
Steps to Reproduce
==================

1. Pair device to headset which supports both A2DP and HFP.
2. Start Music App on the device
3. Audio (A2Dp streaming) will route to headset.
4. Make a call from device to remote phone.
5. Accept the call on the remote side.
6. After some time, terminate call from headset.


Expected Behavior:
=================
A2DP streaming should start after termination of SCO connection immediately

Actual Behavior:
================
A2DP streaming resumes after 15 seconds.

Note:
=====
This behaviour is observed in the following scenarios also:
1. A2DP streaming. Call from device to remote phone. No User action on remote side.
2. A2DP streaming. Call from device to remote phone. Reject call on remote side.
(Reporter)

Updated

4 years ago
Blocks: 942267
blocking-b2g: --- → 1.3?
(Reporter)

Comment 1

4 years ago
Wondering if this is related to bug 952893
(Reporter)

Comment 2

4 years ago
From the logs it can be seen that from frame number 3795 to 5739, scale factors of the packets are 0, which makes them silent packets. Time difference between these packets is 18 seconds. 
Though we are pumping packets to remote, they would not be heard because scale factor values are zero. 
This proves that from audio we are getting silent packets for this duration.

Another observation was that though there is a delay of ~ 19 seconds, there is no loss of audio. After the delay song resumes from the same point where it got suspended. 
From Bluetooth point of view, we are disconnecting HF call, resuming AVDT Streaming, and sending packets at the right time.
The problem is with the packets sent for first 18 seconds which are silent packets.
(Reporter)

Comment 3

4 years ago
(In reply to Greg Grisco from comment #1)
> Wondering if this is related to bug 952893

Could somebody let us know if this is related to 952893?  We were going to try to apply the patches there, but it looks like we'd need a rebase since they don't apply cleanly.
(In reply to Greg Grisco from comment #3)
> (In reply to Greg Grisco from comment #1)
> > Wondering if this is related to bug 952893
> 
> Could somebody let us know if this is related to 952893?  We were going to
> try to apply the patches there, but it looks like we'd need a rebase since
> they don't apply cleanly.

I think it's related to 952893. In Bug 955961 comment 1, Jamin has also mentioned that silent stream would be sent unexpectedly.

I failed to apply patches of bug 952893 either. Those patches should be for m-c not aurora.
If bug 952893 lands does it fix this issue as well?
(In reply to Preeti Raghunath(:Preeti) from comment #5)
> If bug 952893 lands does it fix this issue as well?

Not 100% sure. As Greg and I mentioned in comment 3 and 4, we were trying to apply patches of bug 952893 to the latest mozilla-aurora(1.3) but failed.
blocking-b2g: 1.3? → 1.3+
status-b2g-v1.3: --- → affected
Paul - Is this a dupe of bug 952893?
Flags: needinfo?(paul)
Hi Eric, mind taking this bug? Thanks
Flags: needinfo?(echou)
This really sounds like a dup of bug 952893. Please see c4 and c6 I left.

Please assign to me if the patch of bug 952893 couldn't solve this problem.
Flags: needinfo?(echou)
(In reply to Eric Chou [:ericchou] [:echou] (away from 1/30 ~ 2/4) from comment #9)
> This really sounds like a dup of bug 952893. Please see c4 and c6 I left.
> 
> Please assign to me if the patch of bug 952893 couldn't solve this problem.

Okay - I'm going to dupe this & will suggest to QC to retest post landing of that patch. If it still reproduces post landing, then reopen the bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(paul)
Resolution: --- → DUPLICATE
Duplicate of bug: 952893

Updated

4 years ago
No longer blocks: 942267

Comment 11

4 years ago
after checking with the fixes from bug 952893, still doesnt seem to help. See the playback starts after ~30 secs. Can
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: DUPLICATE → ---

Updated

4 years ago
Blocks: 942267

Comment 12

4 years ago
(In reply to bhargavg1 from comment #11)
> after checking with the fixes from bug 952893, still doesnt seem to help.
> See the playback starts after ~30 secs. Can

Timelag between call hangup -> music start

01-29 15:48:50.322   321   321 D use-Rlog/RLOG-RIL_QC_B2G: [SUB0] [0162]> HANGUP 1
01-29 15:49:17.872  1321  1539 W TrackUtils: AudioTrack created for streamType =1, flags =0

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 13

4 years ago
checked on this further we don't need specifically any BT headset to produce this issue

- Play music on the device
- Initiate a call from the device
- Music pauses
- Answer the call on the other side and disconnect 

Expected:
- Music playback should start immediately

Result:
Takes about ~30 secs for the actual playback to start

Comment 14

4 years ago
jim: after you done with other music blocker, can you check to see whats going on here (folks from taipei are probably most familiar -- but since they are not back until mid next week, can you give it a look)

not sure if this A2DP delay is related to the TonePlayer reset to normal once call is done...

thanks
hema
Flags: needinfo?(squibblyflabbetydoo)
(Assignee)

Comment 15

4 years ago
I could probably pick up a Bluetooth headset at the store tomorrow to test this out if you think that'd be valuable. I'm not sure there's a way to pretend to have a Bluetooth headset though...
Flags: needinfo?(squibblyflabbetydoo)

Comment 16

4 years ago
Jim, please go ahead and get the bluetooth headset to investigate (you will anyway need one for testing music cases) 

Thanks for your help with this one!

Hema
Assignee: nobody → squibblyflabbetydoo

Comment 17

4 years ago
(In reply to Jim Porter (:squib) from comment #15)
> I could probably pick up a Bluetooth headset at the store tomorrow to test
> this out if you think that'd be valuable. I'm not sure there's a way to
> pretend to have a Bluetooth headset though...

please check the updated steps in c13, you dont need a BT headset
Comment hidden (obsolete)
(Assignee)

Comment 19

4 years ago
I worded that poorly. Let's try again:

The description in comment 13 is bug 961986. That's not necessarily the same bug as described in comment 0 (although it's fairly likely that they are). I encourage anyone who *does* have a Bluetooth headset to try to reproduce this bug with the patch I posted in bug 961986. That would save me a trip to the store tomorrow.

Comment 20

4 years ago
(In reply to Jim Porter (:squib) from comment #19)
> I worded that poorly. Let's try again:
> 
> The description in comment 13 is bug 961986. That's not necessarily the same
> bug as described in comment 0 (although it's fairly likely that they are). I
> encourage anyone who *does* have a Bluetooth headset to try to reproduce
> this bug with the patch I posted in bug 961986. That would save me a trip to
> the store tomorrow.

not sure if oncall.js is a new file, i dont seem to find that in my tree..
(Assignee)

Comment 21

4 years ago
(In reply to bhargavg1 from comment #20)
> not sure if oncall.js is a new file, i dont seem to find that in my tree..

If you're looking at the device (or an already-built version of gaia), it's probably in gaia_build_defer_oncall.js, which I think would be hard to patch. I think there's a way for me to distribute a patched version of an app, but I can't find the docs for how to do it.

The patch in bug 961986 should land very soon though (hopefully within the hour, or whenever Travis finishes), so the next gaia build should have my patch in it and ready for testing. I'm not sure when nightlies run though, since I'm used to just pulling from Github and building things myself.

Maybe someone else more knowledgeable about the QA side can answer these questions. It's 1:40 AM here though, so I'm starting to lose coherence and probably wouldn't be much help anyway.

In the end, I guess I need to get a Bluetooth headset anyway, so I might as well pick one up tomorrow to test this bug out. Thanks for taking a look, though!
(Assignee)

Comment 22

4 years ago
I've looked into this, and I'm guessing that something is happening in Gecko. Some observations:

* If I hit this bug and then power-cycle the headset, it doesn't happen again.
* Switching to speaker during the call also prevents this issue from occurring.
* Hiding the dialer after hanging up starts the playback again (probably because it forces something
  to get garbage-collected).
(Assignee)

Comment 23

4 years ago
Do we know if this is a regression or if it's always been this way? If it's a regression, a regression window would be really helpful.
(In reply to Jim Porter (:squib) from comment #23)
> Do we know if this is a regression or if it's always been this way? If it's
> a regression, a regression window would be really helpful.

QA Wanted - can we check if this happens on 1.2?
Keywords: qawanted

Updated

4 years ago
QA Contact: mvaughan

Comment 25

4 years ago
This issue does not reproduce on the 02/03/14 1.2 build on a Buri.

Environmental Variables:
Device: Buri v1.2 MOZ RIL
BuildID: 20140131004004
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: f9f469d5d1e1
Version: 26.0
Firmware Version: V1.2-device.cfg

I will work on finding a regression window for 1.3.
Keywords: qawanted → regression, regressionwindow-wanted

Comment 26

4 years ago
This issue started reproducing on the 11/07/13 1.3 build.

- Works -
Device: Buri v1.3 MOZ RIL
BuildID: 20131106040203
Gaia: 3b5fe429f2414f2a9d7241b311b399033bb10612
Gecko: 9ba3faa35c96
Version: 28.0a1
Firmware Version: V1.2-device.cfg

- Broken -
Device: Buri v1.3 MOZ RIL
BuildID: 20131107040200
Gaia: 42bbe26a72e030faf07a6fc297f61a3a8ccda25b
Gecko: 70de5e24d79b
Version: 28.0a1
Firmware Version: V1.2-device.cfg
Keywords: regressionwindow-wanted
(Assignee)

Comment 29

4 years ago
(In reply to Matthew Vaughan from comment #26)
> This issue started reproducing on the 11/07/13 1.3 build.

Just to confirm, you reproduced using a Bluetooth headset as in comment 0, and *not* using the steps in comment 13, correct?
Flags: needinfo?(mvaughan)

Comment 30

4 years ago
(In reply to Jim Porter (:squib) from comment #29)
> (In reply to Matthew Vaughan from comment #26)
> > This issue started reproducing on the 11/07/13 1.3 build.
> 
> Just to confirm, you reproduced using a Bluetooth headset as in comment 0,
> and *not* using the steps in comment 13, correct?

Correct... I used a Bluetooth headset for testing this issue.
Flags: needinfo?(mvaughan)
(Assignee)

Comment 31

4 years ago
Great, thanks! This is almost certainly another regression from bug 927852, although it's strange that my patch in bug 961986 didn't resolve the issue here as well. I'll keep looking and try to narrow down what's going on. Maybe it's just a bug in WebAudio.
Blocks: 927852

Updated

4 years ago
Component: Bluetooth → Web Audio
Product: Firefox OS → Core
Version: unspecified → 28 Branch
Hi Jim -- Has all the testing for this been on v1.3?  If so, no one has been testing with the patch in bug 961986 because it hasn't been uplifted yet (unless I'm missing something).  This was just made a WebAudio bug (WebAudio is one of the areas I manage);  so I'm trying to figure out if I need to assign a Web Audio developer to this bug or if I can keep them on other important work.  Since this is a 1.3 blocker, this would get top priority. Do you need a Web Audio developer to help you at this point?  Thanks.
Flags: needinfo?(squibblyflabbetydoo)
Ah ha. Didn't notice that bug originally. Yeah, this sounds like a dupe of that bug. Thanks for the help in pointing out that bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago4 years ago
Flags: needinfo?(squibblyflabbetydoo)
Resolution: --- → DUPLICATE
Duplicate of bug: 961986
(Assignee)

Comment 34

4 years ago
No, it's not a dupe. I've been testing on master (i.e. with my patch in bug 961986) with a Bluetooth headset, and I still see the issue. It is, of course, possible that my headset is broken or I'm just dumb, but I'm pretty sure the issue hasn't been resolved yet.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Hi Jim -- Do you need/want help from a Web Audio developer at this point?
Flags: needinfo?(squibblyflabbetydoo)
(Assignee)

Comment 36

4 years ago
That would probably be helpful, yes. I've been meaning to learn more about WebAudio anyway, but having someone who knows the code would probably make this go faster. My suspicion is that what's happening is when oncall.html is unloaded, something in the audio context isn't closing immediately and instead is sticking around until the garbage collector removes it. My patch in bug 961986 works around the issue by setting the audio channel to "normal" when unloading oncall.html, but that doesn't seem to fix the issue when using a Bluetooth headset. I'm not sure why yet.
Flags: needinfo?(squibblyflabbetydoo)
Rob -- Please see Comment 36.  Can you help Jim?  This is a v1.3 blocker that just came up as Web Audio issue within the last day.
Flags: needinfo?(roc)
Priority: -- → P1
(Assignee)

Comment 38

4 years ago
More observations: mozinterruptbegin/mozinterruptend are fired at the expected times on the <audio> element in the Music app. However, the music doesn't start playing (or at least it's muted) until you either wait a long time, or hide the Dialer app.

I also noticed that turning TonePlayer's methods into no-ops actually breaks things even more, much to my surprise. It causes the music to *never* unmute. You have to manually pause/unpause the song to get sound again. I'm guessing something is horribly broken in the audio channel code, but I haven't been able to narrow down what just yet. I would have thought that all the pausing/unpausing stuff was handled in the media elements, but there must be something else going on, since the mozinterruptend event is fired as expected, and the code that does that should be unmuting the Music app's <audio> element at the same time.
It does sound like an audiochannel problem. Hopefully Andrea can help?
Flags: needinfo?(roc) → needinfo?(amarchesini)
(Assignee)

Comment 40

4 years ago
I'm also going to make a guess that the regression range posted above is misleading: I think that's when bug 961986 was born (which is a superset of this issue), but then something else broke later in Bluetooth-related code (or audio channel code). That would explain why bug 961986 doesn't fix things now.

Comment 41

4 years ago
Can we get ETA to fix this bug? Thank you.
(Assignee)

Comment 42

4 years ago
We'd have to figure out what the actual problem is before we could say how long the fix will take (although I suspect that identifying the problem is 95% of the work here).

I've managed to narrow it down somewhat, but based on my understanding of the audio channel code, this should have been fixed by bug 961986. Why it's still broken is a mystery to me. Unfortunately, the first time I looked at this code was last Friday, so I'm mostly going in blind. Hopefully people with some more experience in this area can help out.
(In reply to Jim Porter (:squib) from comment #42)
> We'd have to figure out what the actual problem is before we could say how
> long the fix will take (although I suspect that identifying the problem is
> 95% of the work here).
> 
> I've managed to narrow it down somewhat, but based on my understanding of
> the audio channel code, this should have been fixed by bug 961986. Why it's
> still broken is a mystery to me. Unfortunately, the first time I looked at
> this code was last Friday, so I'm mostly going in blind. Hopefully people
> with some more experience in this area can help out.

I've emailed :baku and requested his help here, we should be hearing from him soon. Hope that helps !
Changing the component to AudioChannel to get the right support for Jim (:squib).
Component: Web Audio → AudioChannel
Product: Core → Firefox OS
Version: 28 Branch → unspecified
> > I've managed to narrow it down somewhat, but based on my understanding of
> > the audio channel code, this should have been fixed by bug 961986.

When an audio call is terminated we enable the audio after 1500 ms. The reason why we do this is:

1. User can have time to remove device from his ear before music resuming.
2. Give BT SCO to be disconnected before starting to connect A2DP.

If we think 1500 is too much, we can reduce it, but I think this is a great feature that we should not kill.
Flags: needinfo?(amarchesini)
> When an audio call is terminated we enable the audio after 1500 ms. The
> reason why we do this is:

Of course 1500ms != 15000ms. This means that this is not the problem I was talking about.
The etienne's patch is landed to 1.3 just 1 hour ago. Are we sure that we are testing the device with that patch included?
(Assignee)

Comment 47

4 years ago
I've been testing on gaia/master and m-c (and I'm the author of the patch in bug 961986). I still experience this issue.

The interesting part is that the patch in bug 961986 fixes the mozinterruptend event; prior to the patch, it takes 15 seconds or so to fire on the Music app's <audio> element. With the patch, it fires almost immediately (after the 1.5 second timeout mentioned in comment 45). However, despite that, the audio is still muted for another 10-15 seconds when using a Bluetooth headset.

Comment 48

4 years ago
Jim tested this with the patch for bug 961986 that he helped fix (the one etienne reviewed: comment 34). 

Is there anyone with the AudioChannel expertise point Jim in the right direction please! Or some from the AudioChannel team please take it over so it will be more efficient. 

NI'ing CJ and Maire to find help (Marco Chen is out till the 9th)

Thanks so much!

Hema
Flags: needinfo?(mreavy)
Flags: needinfo?(cku)
Star Cheng from our team has worked with Marco on AudioChannel-related bugs. I just asked for his help to take a quick investigation.
I don't believe I know anyone who is familiar with the AudioChannel code (other than Marco and :baku).
Flags: needinfo?(mreavy)
I reduplicted the commnet 0 procedure. But I can't dupliate that.

device  :  hamachi
Gaia    :  f55764b3cfb5937e8ca58835342a67059cd3ad8f
Gecko   :  http://hg.mozilla.org/releases/mozilla-aurora/rev/64f3382ec473
BuildID :  20140105004001
Version :  28.0a2

I will try to flash the SW which Matthew Vaughan mentioned in comment 26 and reduplicate it.
(BuildID: 20131107040200 / Gaia: 42bbe26a72e030faf07a6fc297f61a3a8ccda25b / Gecko: 70de5e24d79b)
(In reply to Star Cheng [:scheng]  (away from 1/29 ~ 2/5) from comment #51)
> I reduplicted the commnet 0 procedure. But I can't dupliate that.

I try to hang up the call from Caller and BT headset, and the results are the same.
--> The music stream is resumed immediately to route to the BT headset instead of delay about 15 seconds.

> 
> device  :  hamachi
> Gaia    :  f55764b3cfb5937e8ca58835342a67059cd3ad8f
> Gecko   :  http://hg.mozilla.org/releases/mozilla-aurora/rev/64f3382ec473
> BuildID :  20140105004001
> Version :  28.0a2
> 
> I will try to flash the SW which Matthew Vaughan mentioned in comment 26 and
> reduplicate it.
> (BuildID: 20131107040200 / Gaia: 42bbe26a72e030faf07a6fc297f61a3a8ccda25b /
> Gecko: 70de5e24d79b)

Updated

4 years ago
Flags: needinfo?(cku)

Comment 53

4 years ago
Star is the right person for this bug and he had  look into this bug.
(In reply to Star Cheng [:scheng]  (away from 1/29 ~ 2/5) from comment #51)
> I reduplicted the commnet 0 procedure. But I can't dupliate that.
> 
> device  :  hamachi
> Gaia    :  f55764b3cfb5937e8ca58835342a67059cd3ad8f
> Gecko   :  http://hg.mozilla.org/releases/mozilla-aurora/rev/64f3382ec473
> BuildID :  20140105004001
> Version :  28.0a2
> 
> I will try to flash the SW which Matthew Vaughan mentioned in comment 26 and
> reduplicate it.

I followed the procedure. But I can't duplicate it.
The result --> The music stream is resumed immediately to route to the BT headset.

> (BuildID: 20131107040200 / Gaia: 42bbe26a72e030faf07a6fc297f61a3a8ccda25b /
> Gecko: 70de5e24d79b)

Comment 55

4 years ago
> 
> I followed the procedure. But I can't duplicate it.
> The result --> The music stream is resumed immediately to route to the BT
> headset.

Just to confirm, you made a call from the device right? this issue doesn't reproduce if you make the call from remote side
bhargavg1, thanks a lot. We can reproduce it on QRD8x26 with build 234.
Confirmed even without connecting with Bluetooth headset, delay can be observed on QRD8x26 build 234.
case 1 : after I finish operating the procedure, stay in the dial app.
case 2 : after I finish operating the procedure, press home key to back to home screen.

the result:
case 1 -> resume after 15 sec.
case 2 -> resume after 2 sec.

could anyone provide information about dial app?
The dialer app will create a Web Audio AudioContext to play key tones, and that AudioContext uses an AudioChannel, but comment 38 may exclude involvement of the AudioContext - I'm not clear.  Note
https://github.com/mozilla-b2g/gaia/commit/7ef65d5cbb93d180de36b2f93671856328b8321f

I don't know what else the dialer app does.
(In reply to Star Cheng [:scheng]  (away from 1/29 ~ 2/5) from comment #58)
> case 1 : after I finish operating the procedure, stay in the dial app.
> case 2 : after I finish operating the procedure, press home key to back to
> home screen.
> 
> the result:
> case 1 -> resume after 15 sec.
> case 2 -> resume after 2 sec.
> 
> could anyone provide information about dial app?

Quick note: just tried and had the same observation as what Star found. This reminds me of bug 927852. I reverted the Gaia patch of that bug and the issue was fixed.
Star and I also tried the latest 1.3 build and we found that this issue doesn't exist anymore. Adding qawanted for double confirm.
Keywords: qawanted
Hey Jim,
 
> I've managed to narrow it down somewhat, but based on my understanding of
> the audio channel code, this should have been fixed by bug 961986. Why it's
> still broken is a mystery to me. 

I took an investigation and I think your patch (bug 961986) did fix the issue. Have you tried the latest 1.3 Gaia?
Flags: needinfo?(squibblyflabbetydoo)

Comment 63

4 years ago
This issue does not reproduce for me on the 02/06/14 1.3 build. After ending a call, the music would take ~3 seconds to resume playing.

- Buri 1.3 Build -
Device: Buri v1.3 MOZ RIL
BuildID: 20140206004002
Gaia: 467ef8c9145d9a57d35b0619db541d23b522b958
Gecko: a1fa925c40c2
Version: 28.0
Firmware Version: V1.2-device.cfg
Keywords: qawanted
Hey Bhargav, does this issue reproduce here still with the Gecko/Gaia from comment 63?
Flags: needinfo?(bhargavg1)
(Assignee)

Comment 65

4 years ago
(In reply to Eric Chou [:ericchou] [:echou] from comment #62)
> I took an investigation and I think your patch (bug 961986) did fix the
> issue. Have you tried the latest 1.3 Gaia?

I'll try again, but I've been using the master branch of gaia (1.4, but it should be close to 1.3 since we just branched a few days ago). I also noticed that the issue seems to go away if I power-cycle the Bluetooth headset (see comment 22).
Flags: needinfo?(squibblyflabbetydoo)

Comment 66

4 years ago
(In reply to Michael Vines [:m1] [:evilmachines] from comment #64)
> Hey Bhargav, does this issue reproduce here still with the Gecko/Gaia from
> comment 63?

Dont see this issue on the latest tip build
Flags: needinfo?(bhargavg1)

Comment 67

4 years ago
(In reply to bhargavg1 from comment #66)
> (In reply to Michael Vines [:m1] [:evilmachines] from comment #64)
> > Hey Bhargav, does this issue reproduce here still with the Gecko/Gaia from
> > comment 63?
> 
> Dont see this issue on the latest tip build

Can we duplicate this to bug 961986
(Assignee)

Comment 68

4 years ago
This seems to be working for me now that I updated gecko to the latest greatest. Marking dupe.

Feel free to reopen this if you find that it's still broken.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 961986

Updated

4 years ago
Whiteboard: [CR 595623] → [caf priority: p1][CR 595623]
You need to log in before you can comment on or make changes to this bug.