[TESTING] - NAND OMGB (1.2.3)

[argenisaz]

Originally Posted by argenisaz

Follow up:

Milda25 is correct, missed calls cause the issue and it's easy to replicate.

I wanted to post the cleanest logs possible, so this is what I did:
1. Powered off phone and then back on. Waited until everything settled in (solid green light).
2. Made a call to my cell phone, as expected, no ringtone. I answered the call and audio was ok.
3. Made a second call (ringtone worked as expected), but this time I didn't answer (generating a missed call).
4. Made a third call and this time the ringtone was dead. I answered and there was no audio.
5. Opened music player and audio was also dead. Once again, trying to adjust volume got me "in call" volume slider.
6. Ran getlogs app.

I hope they are useful. I replicated the issue 3 times just to be sure. Phone failed to enter complete sleep state every time (solid orange light).

Another curious detail: when receiving a call, if you dismiss it (slide the red bar, don't let it become a missed call!!!) audio is not lost.

[eurohunter]

Originally Posted by arrrghhh

I'll try to recreate this on HaRET as well, now I'm curious...

On Haret this issue i think was fixed on the latest update with kernel .27. I tried all kinds of calls (missed, ignoring, answering several times). ringtone and sound were still fine.

[arrrghhh]

Originally Posted by eurohunter

On Haret this issue i think was fixed on the latest update with kernel .27. I tried all kinds of calls (missed, ignoring, answering several times). ringtone and sound were still fine.

Hey, thanks for doin my work for me .

Better yet, do you know which commit on .27 it was...? Or perhaps approximately when it was fixed? I don't recall this one in particular.

[Alsel]

Originally Posted by [ACL]

Something is wrong with your setup. EVERYTHING is erroring out. go back to winmo then try agian from scratch.

I tried several times. The result is not achieved. task29 also did not help.

[argenisaz]

Originally Posted by argenisaz

Another curious detail: when receiving a call, if you dismiss it (slide the red bar, don't let it become a missed call!!!) audio is not lost.

My previous report might not be so accurate, today I ignored a call and audio was lost.

[[ACL]]

Originally Posted by arrrghhh

Hey, thanks for doin my work for me .

Better yet, do you know which commit on .27 it was...? Or perhaps approximately when it was fixed? I don't recall this one in particular.

Its most likely this one

Commit in linux-msm in Linux on Qualcomm's MSM - Gitorious

I'm responsible for the main .27, but this acoustic branch that emwe has this commit picked from .35. It's worth a try i suppose.

[detule]

Originally Posted by [ACL]

Its most likely this one

Commit in linux-msm in Linux on Qualcomm's MSM - Gitorious

That's to address the root of all evil (from milda25's log):

[ 4128.015228] snd_set_device -1 1 0

[[ACL]]

Originally Posted by detule

That's to address the root of all evil:

[ 4128.015228] snd_set_device -1 1 0

Lol, root of evil is right. This should be handled in user-land, but extra protection in the kernel does not hurt i suppose. Thanks dood.

[argenisaz]

Originally Posted by argenisaz

My previous report might not be so accurate, today I ignored a call and audio was lost.

Ok, I would be great if someone else could test these two scenarios and post back results, these are mine:

A. In coming callm dissmissed using on screen slider. Result: dead audio.

B. In coming callm dissmissed using physicall end call button. Result: audio does not die, works perfectly.

I haven't had a chance to recreate option B again, but it's worth a shot. I'll try to grab logs and post my findings.

[milda25]

Originally Posted by argenisaz

Ok, I would be great if someone else could test these two scenarios and post back results, these are mine:

A. In coming callm dissmissed using on screen slider. Result: dead audio.

B. In coming callm dissmissed using physicall end call button. Result: audio does not die, works perfectly.

I haven't had a chance to recreate option B again, but it's worth a shot. I'll try to grab logs and post my findings.

I tested this with my wife. She called me and I make scenario A: audio died.
Then reboot to fix the audio.
Second call from my wife and I make scenario B: audio doesn't die.
Then third call from my wife and I make scenario B again: audio died this time. Odd thing ...
If you need logs for every each scenario I can post it next day. In our country is too late now

Sent from my Touch Pro 2 using Tapatalk