[scenario] playing background music - select clock ringtone preview - pause music - play clock ringtone - slelect another ringtone - resume music shortly - play clock ringtone [issue] Don`t resume music shortly when select another ringtone. [suggesion] This case should need senario improvements. Because gecko/qualcomn can`t adjust timing only for this case, You should change scenario that don`t resume music when user select the other ringtone list. In a diffrent way, It takes interval time when select the ringtone list. Thanks.
Looks like a timing issue for switching channel when pause() a playing ringtone and set a new ringtone to play() in alarm channel. Macro, In the scenario, could we set a new ringtone to play() directly without pause() the playing ringtone? I'm not sure that it is a workaround or not. Do you have any idea?
Note: depend on Bug 829409
May I check when we receve all patch include Bug 829409? This patch isn`t released in the recent version. If you need more modification, let me know progress.
dose anybody recomment about your patch? I wanna patch date or version. leo currently use ver 1.01.
More information would greatly help in making the decision whether or not to block the release on this. Please elaborate on comment 0 and re-nominate if it's still a stop-ship issue. Thanks.
We like to avoid resuming the music shortly when another ringtone is pressed. Because Music is automatically resume or pause by AudioChannelService in gecko layer, It is not easy to modify that music isn`t resume in gaia`s ringtone list. So i woluld recommand how to add the exception API for playing another ringtone directly. Let you know this`s priority after discussing with leo manager.
We think it is not a serious issue after discussing about it. We need the final decision of quality management department. We will keep status for a while. thanks.
I'd like to get a UX opinion on this bug -- I find the current state acceptable and would support resolving as worksforme. Admittedly, there is some strangeness here where some of the sounds are very short (Classic Pulse) and others are quite a bit longer (Classic Pulse Progressive) so you don't have great predictability about when exactly the tone will end and the music will restart.
Dylan, I think this issue is about the audio competing policy, currently there are gaps between the alarm(clock) and content(music) channels while switching one to another. We can probably use some tricks in clock to avoid these gaps, but similar scenario will also happen like picking ringtones in settings(Setting > Sound > Ringer) when playing music in the background(Currently those two channels will be mixed together because ringtones app did not set the mozAudioChannelType properly, I will file a new bug later). So let's keep this bug open and change the component to AudioChannel, next week we will have a workshop in Taipei office to discuss about, how to improve the audio competing policy, we should have some result and will update here, thanks.
In UX perspective, I suggest that when the user enters ringtone preview, the background music should always pause until the user leaves the page. The behaviour of selecting ringtones / ringer shouldn't be interrupted by background music.
(In reply to Juwei Huang from comment #10) > In UX perspective, I suggest that when the user enters ringtone preview, the > background music should always pause until the user leaves the page. The > behaviour of selecting ringtones / ringer shouldn't be interrupted by > background music. Thanks, Juwei, and after the offline meeting with ux team and gecko devs, we also agreed with the behaviour in comment 10. Due to the current audio competing policy, we are unable to fix it without some workarounds, so I turned to study the web audio api and see if the technique can fix it. By doing some experiments, fortunately, I found using the web audio can fix it perfectly! and the same technique fixes bug 958470 as well, so I am going to write a patch, though this is not a blocker but fixing this can make big changes on the user experiences.
Update: Since bug 959020 is requesting the feature that users can select user-defined ringtone to alarm, also the ringtones app is integrating the music pick activity, to be able to select ringtones from user's collection in bug 960329, in theory, clock should also pick the alarm tones from the same ringtones app, so this audio competing issue will be transferred to the ringtones app, which I already have a reviewing patch(bug 958470) and will fix both bug 958470 and this bug. Apparently this issue should depends on bug 958470, and hopefully after clock use the ringtones pick activity to set the alram tones, this bug will be fixed automatically.
Backlog - this doesn't hit the QC needs list & DSDS needs list, so this doesn't block.
This issue resolved-patch is different with the patch depends on 958470.
Clock rintone does not select from rintone App, and mozAudioChannelType is alarm. We need modify alarm_edit.js and time_panel.js file to resolve this issue.
Has this been fixed yet?
(In reply to Patryk Adamczyk [:patryk] UX from comment #16) > Has this been fixed yet? This issue has been resolved