1. Title : When user turn screen off using power key, AP(CPU) doesn't enter sleep mode because of audio interrupt 2. Precondition : In call state 3. Tester's Action : Turn screen off using power key 4. Detailed Symptom : AP(CPU) doesn't enter sleep mode 5. Expected : AP(CPU) enter sleep mode 6. Reproducibility: Y 1) Frequency Rate : 100% This issue is shown when Bug 1016277 patch is applied

Hi Fabrice, Could you please kindly spare some time to look into this? It seemed this issue is introduced after Bug 1016277 patch is applied. May you please help on this ? Thank you very much!

Hi Shawn, Could you please find someone to check this ? Thank you very much !

Hi, Could you please provide more details and STR, or any related log for investigation ? Thank you very much!

Reproduced steps : 1) In call 2) Press power key We check kernel logs only when we find this issue When you check kernel logs, we found below logs <6>[ 396.021658] PM: suspend entry 2014-09-25 09:18:12.205281224 UTC <6>[ 396.249049] PM: suspend exit 2014-09-25 09:18:17.274341171 UTC <6>[ 396.249250] PM: suspend entry 2014-09-25 09:18:17.274552733 UTC <6>[ 396.327557] PM: suspend exit 2014-09-25 09:18:17.352856223 UTC Periodically, suspend entry / suspend exit log are shown in kernel logs. When we test old version(20140627), device doesn't show these logs periodically. Thank you

I tried to profiling this cases and got some findings: 1. There is no wake lock was held during phone call. 2. By dmesg, system is waked up by interrupt irq 188 and 200 <6>[ 151.067289 / 01-02 19:03:31.068] Disabling non-boot CPUs ... <6>[ 151.070375 / 01-02 19:03:31.089] CPU0: msm_cpu_pm_enter_sleep mode:3 .... <4>[ 151.070375 / 01-02 19:03:31.089] gic_show_resume_irq: 188 triggered smd_dev <4>[ 151.070375 / 01-02 19:03:31.089] gic_show_resume_irq: 200 triggered smd_dev <6>[ 151.070685 / 01-02 19:03:31.098] Enabling non-boot CPUs ... 3. The status of irq 188 and 200 in /proc/interupts during 30s phone call before, after 188: 2461 5009 200: 5962 22489 As I remember, smd_dev interrupt should be related to modem, so we might need partner's help to clarify it.

dmesg/wakelock/interrupts status before/after 30s phone call test.

Hi Danny, 188 is the interrupt related ADSP. and smd_dev interrupt is added by "AudioCompetingHelper". If we disabled "AudioCompetingHelper", issue is not reproduced. Please give us some information what is the "AudioCompetingHelper" and whether interrupt is needed during call.

Hi Wayne: Per comment 7, is there anything we can help answering? Thanks!! Shawn

Hi Steven As offline talk, please help check it. thanks

Hi Maire As comment 0, it's resulted from bug 1016277. Can you find someone to fix the problem? Thanks.

This issue is outside of WebRTC and Web Audio; so no one on my team would be able to fix this. However, Andrea may be able to -- or may know who can. Hi Andrea -- Do you think you could take this bug? Or do you know someone else who would be a good fit for fixing this? Thanks!

Dear all Is this any updates on this bug? Thank you

> 188 is the interrupt related ADSP. > and smd_dev interrupt is added by "AudioCompetingHelper". What can generate this snd_dev interrupt? Events/Messages or just an active WebAudio AudioContext object? What AudioCompteingHelper does is to play silent using a telephony AudioContext. Can it be that, having this element active, we generate smd_dev interruptions? If this is the issue, we can easily fix this removing these lines from the compete() function: + _silenceBufferSource = _ac.createBufferSource(); + _silenceBufferSource.buffer = _ac.createBuffer(1, 2048, _ac.sampleRate); + _silenceBufferSource.connect(_ac.destination); + _silenceBufferSource.loop = true; and set to null _ac in leaveCompetition(). I can send a patch if this is the reason of this issue.

(In reply to Andrea Marchesini (:baku) from comment #13) > > 188 is the interrupt related ADSP. > > and smd_dev interrupt is added by "AudioCompetingHelper". > > What can generate this snd_dev interrupt? Events/Messages or just an active > WebAudio AudioContext object? > > What AudioCompteingHelper does is to play silent using a telephony > AudioContext. Can it be that, having this element active, we generate > smd_dev interruptions? > > If this is the issue, we can easily fix this removing these lines from the > compete() function: > > + _silenceBufferSource = _ac.createBufferSource(); > + _silenceBufferSource.buffer = _ac.createBuffer(1, 2048, _ac.sampleRate); > + _silenceBufferSource.connect(_ac.destination); > + _silenceBufferSource.loop = true; > > and set to null _ac in leaveCompetition(). > I can send a patch if this is the reason of this issue. I am not a proper guy to answer Andrea's question. Rachelle, could you help to find owner to answer the questions?

I try to dump media.audio_policy and found refCount of voice /system stream is 1. So that would cause system can't enter sleep stage. This bug:1088668 may also affect this issue.

Based on comments from Randy, this bug could be solved when Bug1088668 is resolved which is planned on 2.1 or 2.2 release. thanks!

Bug 834530 now landed, it should provide a permanent fix for this issue. Could you re-test with the patch applied and confirm that the problem is gone? We'll close the bug only when it's confirmed to be fixed.

Any updates here? After bug 834530 landed I've got multiple reports of the Flame's battery life greatly improving so I hope this should be fixed for good.

Since there hasn't been any updates this I'm closing it as I'm pretty sure that this was fixed as part of bug 834530. Please reopen in case this is still a problem.