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.

Wondering if this is related to bug 952893

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.

(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.

Paul - Is this a dupe of bug 952893?

Hi Eric, mind taking this bug? Thanks

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.

(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.

after checking with the fixes from bug 952893, still doesnt seem to help. See the playback starts after ~30 secs. Can

(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

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

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

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...

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

(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

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.

(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..

(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!

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).

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?

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.

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

(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?

(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.

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.

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.

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.

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.

Hi Jim -- Do you need/want help from a Web Audio developer at this point?

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.

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.

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?

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.

Can we get ETA to fix this bug? Thank you.

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).

> > 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.

> 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?

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.

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

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).

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)

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)

> > 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.

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?

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

Hey Bhargav, does this issue reproduce here still with the Gecko/Gaia from comment 63?

(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).

(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

(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

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.