Closed Bug 1145067 Opened 10 years ago Closed 7 years ago

[Nexus 5][Music]During a call, we can play the music, but when our face get close to screen in a calling, the music will be paused.

Categories

(Firefox OS Graveyard :: AudioChannel, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog, b2g-v2.2 affected, b2g-master affected)

RESOLVED WONTFIX
tracking-b2g backlog
Tracking Status
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: huayu.li, Unassigned)

Details

(Whiteboard: [2.2-nexus-5-l])

Attachments

(1 file)

Attached file logcat1.txt
[1.Description]: [Nexus 5 v2.2&3.0][Flame 2.2][Music]Music should not be able to be played during a call,this issue doesn't exist while with a BT device and headset. Occurence time:15:32 see attachment:logcat1.txt [2.Testing Steps]: 1.Launch dialer and establish a call. 2.Launch music and play a song. 3.Put device close to our face. [3.Expected Result]: 2.Music cannot be played. [4.Actual Result]: 2.The music can be played. 3.The music will pause, after put device far away from our face, music will continue. [5.Reproduction build]: N5 2.2[Affected]: Build ID 20150318002504 Gaia Revision 306772a58335ac4cad285d27c3805090a8cc6886 Gaia Date 2015-03-17 17:12:36 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/a6f5f4035ea5 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150318.040241 Firmware Date Wed Mar 18 04:02:56 EDT 2015 Bootloader HHZ12d N5_3.0[Affected]: Build ID 20150318055750 Gaia Revision b8051d370ddf4e5bd8e7d8a19fb9eeb5fd6ffb39 Gaia Date 2015-03-18 07:48:50 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/41a61514461e Gecko Version 39.0a1 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150318.093541 Firmware Date Wed Mar 18 09:35:58 EDT 2015 Bootloader HHZ12d Flame 2.2 build[Affected]: Build ID 20150318002504 Gaia Revision 306772a58335ac4cad285d27c3805090a8cc6886 Gaia Date 2015-03-17 17:12:36 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/a6f5f4035ea5 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150318.040534 Firmware Date Wed Mar 18 04:05:45 EDT 2015 Bootloader L1TC000118D0 [6.Reproduction Frequency]: Always Recurrence,5/5 [7.TCID]: Free Test
We can play music in a call, not sure what was the use for that, but my android does that too. ni ux for comment.
Flags: needinfo?(cawang)
My Iphone does this too (I can hear the music, but the other side can't), but I can't imagine the use case of the feature. In fact, if the music is playing, it's really impossible to continue the conversation. I'd suggest removing the function or can we ping anyone who planned the feature or knew the background story here? Thanks!
Flags: needinfo?(cawang)
(In reply to Carrie Wang [:carrie] from comment #2) > My Iphone does this too (I can hear the music, but the other side can't), > but I can't imagine the use case of the feature. In fact, if the music is > playing, it's really impossible to continue the conversation. I'd suggest > removing the function or can we ping anyone who planned the feature or knew > the background story here? Thanks! I can't imagine this use case, too. However, maybe there is somebody in the world who likes to play a background music during their conversion... Dominic, how do you think?
Flags: needinfo?(dkuo)
(In reply to Hermes Cheng[:hermescheng] from comment #3) > (In reply to Carrie Wang [:carrie] from comment #2) > > My Iphone does this too (I can hear the music, but the other side can't), > > but I can't imagine the use case of the feature. In fact, if the music is > > playing, it's really impossible to continue the conversation. I'd suggest > > removing the function or can we ping anyone who planned the feature or knew > > the background story here? Thanks! > > I can't imagine this use case, too. However, maybe there is somebody in the > world who likes to play a background music during their conversion... > > Dominic, how do you think? Actually this is an expected behaviour and if I recalled correctly, we have this since v1.x. We didn't change anything and will not I guess, also this is already specified in the sound spec(bug 1068219), the content(Music) channel is able to play during the telephony(Callscreen) channel active, but it only happens when the app with content channel is in the foreground, which means it should be the user brought/launched the app to foreground, so we allow it to play audio. But I don't know why when the phone gets close to face then it paused the music, I can inveterate this if it blocks something.
Flags: needinfo?(dkuo)
And this might be more suitable to put in the AudioChannel Component because Music app does not handle the audio channel things.
Component: Gaia::Music → AudioChannel
Hi, all, Is it still a bug issue? As the Comment4, this behavior is allowed from our sound spec. If user want to play music, we should not prohibit it.
I think the audio is automatically paused by the proximity sensor when the user puts his/her face close to continue the conversation. One use case I can imagine is to let the other party hear the music that is currently playing. From the comments, it does not sound like it's an issue for anyone (1. it's according to the spec, 2. it does not block the user from performing intended task 3. this bug hasn't been touched for 3+ months) so I'll close it, and if others disagree, it can be reopened.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
(In reply to No-Jun Park [:njpark] from comment #7) > I think the audio is automatically paused by the proximity sensor when the > user puts his/her face close to continue the conversation. One use case I > can imagine is to let the other party hear the music that is currently > playing. Hi, park Accoring to the spec, Music should be abled to be played during a call, but I try to do the STR in comment 0 on iphone6, the music won't stop while we put the devie close to our face, maybe user want to hear the music during a call without headphone or speaker ? May I know your idea?
Flags: needinfo?(npark)
(In reply to Alissa from comment #8) > > Hi, park > Accoring to the spec, Music should be abled to be played during a call, but > I try to do the STR in comment 0 on iphone6, the music won't stop while we > put the devie close to our face, maybe user want to hear the music during a > call without headphone or speaker ? May I know your idea? Hi Alissa, In the sound spec version 1.51 (bug 1068219), on page 12 *1, it says: "An active app can decide whether or not to pause sound coming from other inactive apps. An inactive app can decide whether or not to resume when the channel is no longer in use. - FM/Music: Paused and UI disabled during a call. FM/Music resumes after the call." I think it pauses the music when face is close to the phone because the call app thinks 'channel is in use.' When face is not close to the phone, then it can be assumed that the user is not on call and music is resumed. If what I think is true, then music should be always paused in speakerphone mode though. (I can't test this right now, but if this is not the case, then we should reopen this bug)
Flags: needinfo?(npark)
(In reply to No-Jun Park [:njpark] from comment #9) > If what I think is true, then music should be always paused in speakerphone mode > though. (I can't test this right now, but if this is not the case, then we > should reopen this bug) Hi, park If we launch music and play a song in speakerphone mode, the song can be played in speaker, but if we exit playing page[or screen time out], music will be paused. After entering playing page again, music will continue automatically, the result seems to be the same as that when P-sensor is on: If music playing page is hid during a call, music will be paused.
Flags: needinfo?(npark)
(In reply to Alissa from comment #10) > Hi, park > If we launch music and play a song in speakerphone mode, the song can be > played in speaker, but if we exit playing page[or screen time out], music > will be paused. After entering playing page again, music will continue > automatically, the result seems to be the same as that when P-sensor is on: > If music playing page is hid during a call, music will be paused. I'm guessing the phrase "FM/Music: Paused and UI disabled during a call" (from the sound spec) means that 'during a call' is true only when the dialer app is active. When the music app becames active, then the dialer app will become inactive in turn, and according to the spec the music will be played. But then again, if I'm in a call on speakerphone mode, wouldn't I always be 'in a call?' I think UX can make a judgment here, ni?ing tif on this matter to determine whether it's an UX inconsistency or not. (i.e., whether placing my face close to the phone == music app inactive, AND opening music app deliberately while in a call != during a call)
Flags: needinfo?(npark) → needinfo?(tshakespeare)
There's a lot of inconsistencies going on here. As pointed out in previous comments, just because dialer app is not in the foreground (multi-tasking!!) or the phone isn't next to my face (speakphone, putting the phone down for a second, etc) doesn't mean I'm not in a call. We should determine whether or not to play music while a call is active and implement that consistently rather than trying to guess the user's intent and failing. I can imagine this scenario - I'm on the phone and my ear is getting tired so I want to switch sides. I pull the phone away from my face, I do not want music to randomly start playing and then stop again when I put the phone to my other ear. NI'ing Harly to make the call (no pun intended!) for music to be paused during a call or not. Thanks!
Flags: needinfo?(tshakespeare) → needinfo?(hhsu)
I think is either we let user listen to music while during a call(should still play music when the phone is next to user's face). Or we don't allow user to play music during the call(disable music controls). Ni Tori to loop, as she will be the UX owner for audio compete.
Flags: needinfo?(hhsu) → needinfo?(tchen)
Reopening per Comment 12
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
[Tracking Requested - why for this release]: Moving to backlog since it's not a blocker
Flags: needinfo?(tchen)
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 9 years ago7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: