[GitHub issue by tonychung on 2012-09-12T05:48:45Z, https://github.com/mozilla-b2g/gaia/issues/4609] Music continues to play through the phone at a reduced volume when dialing or receiving a call. ## Environment : * Otoro daily: 9-11-2012 * gaia commit: 6cb41daf1073643c86d74624dd8cf55950171e3d * gecko commit: 105845cdabbd043b9975a6937ebd84e3ff4cdca3 ## Repro : 1. Launch the Music App and play a song either through the device speaker or your headphones 2. switch to dialer app, and make an outgoing call to another phone 3. Verify once the call is connected, the music has softened, but its still playing while the call is connected. 4. Repeat steps 1-3, except this time, answer your phone with music playback from another phone. ## Expected : * Music playback should pause (maybe even fade out slowly, and fade back in -- @jcarpenter?) , when a call is connected. ## Actual : * Music playback continues to play on the phone at a reduced volume. it's soft, but its annoying enough that it interrupts the call.

[GitHub comment by jcarpenter on 2012-09-12T06:05:13Z] Agreed. Audio volume should reduce to zero, via a .5-2 second fade out, and then back in to it's previous volume once the call has concluded. cc'ing @aymanmaat @caseyyee for confirmation. They are responsible for Dialer and Sound UX, respectively. The full picture may be more complex.

[GitHub comment by nhirata on 2012-09-12T17:12:15Z] related to #3720; it's not just the music app... we have to worry about video and browser as well.

[GitHub comment by timdream on 2012-09-13T05:41:28Z] I try to reproduce this issue ..... but the Music app crashes when the phone call is connected!!

[GitHub comment by timdream on 2012-09-13T05:41:48Z] That kind of solves the issue right?

[GitHub comment by tonychung on 2012-09-13T06:08:55Z] hah! no.

[GitHub comment by timdream on 2012-09-13T06:09:48Z] @tonychung I was kidding lah.

[GitHub comment by caseyyee on 2012-09-19T01:31:33Z] Just to expand on Josh's recommendation Incoming call while music is playing: - Incoming call screen should be displayed. - Music should fade out and paused - Phone ring should playback in headset. At this point, the user either accepts the incoming call or declines the call. Once the call activity is ended: - Music is is played. - Volume fades back up to previous levels. There are other cases as well such as Outgoing calls, Incoming SMS alerts, notifications, etc. These are being detailed in a audio prioritization matrix that I'm working on. I will update this issue when i have updates to post.

[GitHub comment by jcarpenter on 2012-09-19T01:51:12Z] > * Incoming call screen should be displayed. * Music should fade out and paused * Phone ring should playback in headset. @timdream, just to clarify: those three steps should happen simultaneously. > There are other cases as well such as Outgoing calls, Incoming SMS alerts, notifications, etc. These are being detailed in a audio prioritization matrix that I'm working on. I will update this issue when i have updates to post. @caseyyee [Larissa's comment](https://github.com/mozilla-b2g/gaia/issues/2562#issuecomment-8518083) in #2562 is relevant also.

[GitHub comment by timdream on 2012-09-19T03:15:03Z] @jcarpenter we don't have a mean to do audio prioritization :-/ That requires platform support ...

[GitHub comment by autonome on 2012-09-21T16:17:26Z] @timdream can you file the platform bug? Discussed in triage and sounds like platform solution is the only way to solve problems like cancelling music during emergency calls.

[GitHub comment by alivedise on 2012-09-28T04:00:27Z] Also relevant: #5363

[GitHub comment by jcarpenter on 2012-09-28T05:41:08Z] @caseyyee To put this on your radar

Does this depend upon bug #795237?

Vivien, who can take a look at this?

Music app app would need to specify audio stream type properly. That is bug 796628.

Increasing the priority based on partner request.

New feature work so tagged as feature and P1

Need an owner here. I doubt Vivien has cycles for this.

I believe Marco/Randy is owning...not sure who is owning gecko side. We have a proposal about audio competing policy here: https://docs.google.com/file/d/0BxKpB0y8NZSHYjhJeUtQUkRQVUU/edit?pli=1

tentatively assigned to Marco as this is blocked by bug #805333.

We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule). If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

This bug has been called out as likely having risk to non-B2G platforms. Given that, marking as P1, and moving into the C2 milestone. We should prioritize this landing to mozilla-beta as soon as possible, to prevent late-breaking regressions to other platforms.

Just find the same issue on unagi daily build 11/22/2012. Please also note that not only the music is playing, there are still some other side effects. Whatever you said to phone wont be transmit to the received/dialed caller when there is a music app on the background.

Dominic, once bug 805333 is fixed, what is the expected time to fix this?

Hey Dietrich, after bug 805333 is fixed, Music app should receive some events like mozinterruptbegin/mozinterruptend, what Music needs to do is handling these events, and maybe pause at mozinterruptbegin, resume at mozinterruptend. This won't be too hard and takes little time to fix.

Hi Dominic, now that 805333 landed, can you keep everyone updated as to where you are with the bug? thanks

We also need bug 815445 for this to work.

(In reply to Dominic Kuo [:dkuo] from comment #27) > Hey Dietrich, after bug 805333 is fixed, Music app should receive some > events like mozinterruptbegin/mozinterruptend, what Music needs to do is > handling these events, > and maybe pause at mozinterruptbegin, resume at mozinterruptend. > This won't be too hard and takes little time to fix. I'm not sure if there's any followup work needed here after bug 815445 to resume music after a call, but if so let's file that as a followup bug. NB: marking RESO FIXED when these bugs hit beta because it's getting hard for b2g folks to track remaining work for upcoming milestones.

There is one follow up work for Music app, please see bug 819873, thanks.

I can still reproduce this issue. I assume it'll get fixed when bug 819873 is addressed

Bug 819873 wasn't supposed to have been needed for this ...

Oh my bad. I (wrongly) assumed the incoming call use case also be solved by this. The outgoing call use was is fixed.

Any chance that when bug 819873 is solved the incoming call use case is solved?

Both incoming and outgoing calls should have been fixed automatically once bug 805333 and bug 815445 was fixed. Are you sure this doesn't work? Marco: Can you debug what's wrong here?

Works for incoming call too! Must've not picked up the fix right before. Thanks!

I can verify this is fixed using the latest nightly build (20121212). I tested both incoming and outgoing calls with music playing and I no longer hear the music.