| 11:56 | dcordes_ | hi |
| 12:08 | zeusk | hey |
| 21:48 | [acl] | emwe ? |
| 21:48 | [acl] | damn :-( |
| 21:51 | arrrghhh | he's been scarce lately. |
| 21:53 | detule | hi [acl] |
| 21:56 | [acl] | detule, |
| 21:56 | [acl] | sup |
| 21:56 | [acl] | anuone seen emwe around |
| 21:58 | arrrghhh | he's on gtalk |
| 21:58 | arrrghhh | pinging him |
| 21:58 | [acl] | turn on the bat signal |
| 21:58 | detule | [acl], you think obtainBuffer is caused by a different failure on haret vs nand? |
| 21:59 | [acl] | detule: hmm... what ? let me pull up some code to see what u mean |
| 21:59 | detule | oh from skimming your thread it seemed you thought they were different issues |
| 21:59 | detule | perhaps i misunderstood |
| 22:00 | [acl] | what issue ? sorry |
| 22:00 | detule | obtainBuffer time out |
| 22:00 | [acl] | let me pull up the thread |
| 22:01 | detule | re: http://forum.ppcgeeks.com/android-tp2-development/147260-testing-nand-omgb-1-2-3-a-107.html#post2164974 |
| 22:03 | [acl] | ahh |
| 22:03 | [acl] | obtainBuffer timed out (is the CPU pegged?) 0x46dd50 user=000012c0, server=00000000 |
| 22:03 | [acl] | this bullshit |
| 22:04 | [acl] | well we dont see that bug often if at all. I havent had anyone report that yet .. wet at least its not in the logs they send |
| 22:04 | [acl] | arggg had it from haret logs |
| 22:04 | detule | okay |
| 22:04 | [acl] | but so far the omgb logs people sent haven had it. maybe i missed it |
| 22:04 | [acl] | BUT i did see it |
| 22:04 | detule | it is a routing issue |
| 22:04 | [acl] | with different csvs |
| 22:04 | detule | rather than csv imo |
| 22:05 | [acl] | yeah |
| 22:05 | Cotulla | y0 doods? |
| 22:05 | [acl] | there was so much going on |
| 22:05 | [acl] | that i think its routing as well. at least thats how i was able to replicate it |
| 22:05 | [acl] | just keep changing route paths.. |
| 22:05 | detule | we have a patch for it |
| 22:05 | [acl] | i saw the patch. looks good |
| 22:06 | [acl] | this patch is the one that worries me |
| 22:06 | [acl] | http://gitorious.org/xdandroid/hardware_msm7k/commit/d292cc351ef11abd9a9b8a2448459429977cc567 |
| 22:06 | [acl] | well not worries me just wondering whats the story behind it |
| 22:06 | detule | well looking at your new ring hack it seems you agree get_current_stream is not working properly |
| 22:07 | detule | that function is not in CA, something that JB added... |
| 22:07 | [acl] | well our ring issue was different. It was a combination of things. |
| 22:07 | detule | i thought it was that bEnableOut wasn't being set properly |
| 22:07 | [acl] | thing is, when a ring comes in. We change the mode to RINGTONE |
| 22:08 | [acl] | but right before it, cdma changes the route path to the headset |
| 22:08 | detule | that might be incorrect but the problem is get_current_stream not returning properly |
| 22:08 | [acl] | we never got that far |
| 22:09 | detule | you address the issue here https://github.com/acl/device_htc_rhodium/commit/4333f792b7cd3926e56e7e6620e700bc7f728a86 |
| 22:10 | [acl] | yup |
| 22:10 | detule | bCurrentOut should be different than default |
| 22:10 | detule | but it's not |
| 22:10 | [acl] | i know, but look at the line above |
| 22:10 | detule | because get_current_stream doesn't work proberly |
| 22:10 | [acl] | if (( mCurSndDevice != SND_DEVICE_IDLE ) && (mCurSndDevice == SND_DEVICE_SPEAKER)) { |
| 22:11 | [acl] | set_volume_rpc(SND_DEVICE_CURRENT, SND_METHOD_AUDIO, 0); |
| 22:11 | [acl] | was getting called which shouldnt right ? according to the comments |
| 22:12 | detule | that could be incorrect but bCurrentOut comes into the function already set improperly |
| 22:12 | [acl] | yeah |
| 22:12 | [acl] | that part is true. but we had a combo of issues. So it wasnt just that. thats what i mean |
| 22:13 | [acl] | i dunno why cdma changes sound route before a ring |
| 22:13 | [acl] | gsm is fine |
| 22:13 | [acl] | so is sip |
| 22:13 | [acl] | but cdma does it because telephony reports a connection change. and somehow the sound route defaults to handset |
| 22:14 | [acl] | so right now the hack is just to always set bEnableOut to true when in ring mode |
| 22:14 | detule | get_current_stream doesn't really serve a purpose |
| 22:14 | detule | it's called after we've already written two buffers to the device |
| 22:14 | [acl] | i think JB had a bigger plans ? |
| 22:14 | [acl] | lol |
| 22:15 | [acl] | im not sure why its there myself |
| 22:15 | detule | at that point i can't envision a scenario where we would want bEnableOut to be false |
| 22:17 | detule | btw that Failed to open ringtone null issue i think comes out of the ril |
| 22:17 | [acl] | detule: really? |
| 22:18 | [acl] | interesing |
| 22:19 | detule | but adding a sanity check in Ringer.java whther customRingtoneUri = null is a much better approach IMO than hunting down why the ril notifies RING rather than new incoming connection |
| 22:19 | [acl] | doesnt it already do it? check for null i mean |
| 22:20 | detule | no |
| 22:20 | [acl] | damn |
| 22:21 | [acl] | that sucks. i didnt even look into that |
| 22:21 | [acl] | removing benableout requires an acoustic change too |
| 22:21 | [acl] | damn |
| 22:22 | detule | i think here https://gitorious.org/xdandroid/packages_apps_phone/blobs/gingerbread/src/com/android/phone/Ringer.java#line288 |
| 22:22 | detule | no need to remove bEnableOut, as that guy get's set by other calls |
| 22:22 | detule | not just get_current_stream |
| 22:25 | detule | ugh i mean bCurrentOutStream |
| 22:26 | detule | bEnableOut i think serves a purpose |
| 22:28 | [acl] | ok, lets assume bCurrentOutStream is removed. |
| 22:28 | [acl] | what will trigger benableout to be true |
| 22:29 | detule | i don't think bCurrentOut needs to be removed either :) |
| 22:29 | detule | it gets reset in standby as well as in the destructor |
| 22:29 | detule | in addition to being set by get_current_stream |
| 22:31 | [acl] | im just looking for a patch we can agree on so i can run xdandroid code again. lol. |
| 22:32 | arrrghhh | hah |
| 22:32 | [acl] | bCurrentOutStream does look useless. But removing it frmo the condition will still fail on ring. Since it will only depend on the in_call val |
| 22:33 | [acl] | unless we remove the whole condition and just have bEnableOut set to true by default |
| 22:34 | detule | hm, there may be instances when bEnableOut = false is needed |
| 22:36 | [acl] | like ? |
| 22:36 | detule | when it calls standby |
| 22:39 | [acl] | not in geneal i mean in terms if this specific condition https://github.com/acl/device_htc_rhodium/blob/4333f792b7cd3926e56e7e6620e700bc7f728a86/libaudio-wince/AudioHardware.cpp#L805 |
| 22:41 | detule | that's what I mean, if in some circumstance standby() gets called, this guy resets bCurrentOutStream to default leading to bEnableOut being false which makes sense if we are trying to put some device in standby....if you get rid of bCurrentStream/bEnableOut it won't see that |
| 22:42 | detule | don't know a lot of "if this" "if that" wish JB was around |
| 22:44 | [acl] | but then you will be with a broken ringer again |
| 22:44 | [acl] | lol |
| 22:46 | [acl] | Either way, this should be reverted. http://gitorious.org/xdandroid/hardware_msm7k/commit/d292cc351ef11abd9a9b8a2448459429977cc567 |
| 22:46 | [acl] | if its not being used, lets removed it or cook up something nice |
| 22:48 | [acl] | detule: the only thing i need emwe to commit is this. https://github.com/acl/device_htc_rhodium/commit/f82bcf47a0348ca5b3b36c5c3f550d0ad9456535 |
| 22:48 | [acl] | so i can merge back into the main acoustic |
| 22:49 | [acl] | that LOGE ontop is not really an error. |
| 22:49 | [acl] | so should be LOGI |
| 22:49 | [acl] | i dont care much for the line below. Just had it for debugging |
| 22:49 | detule | that LOGE is unfortunate |
| 22:50 | [acl] | i its not needed, just LOGV that bad boy :-p |
| 22:52 | detule | in terms of d292cc351ef11abd9a9b8a2448459429977cc567 , that's somewhat temporary if people continue to report working ringers i agree get_current_stream should be taken out completely |
| 22:53 | detule | i just didn't want to go deleting JBs code |
| 22:53 | [acl] | yeah i rather add myself :-p |
| 22:56 | [acl] | detule: have you been able to replicate the obtainBuffer error on demand ? |
| 22:57 | detule | there were gbx0b people on .27 that could do it...on 3.1 i never could |
| 22:57 | detule | the kernel patch is the business there |
| 22:57 | [acl] | how can they replicate ? |
| 22:57 | detule | something about missing a call |
| 22:58 | [acl] | haha |
| 22:58 | detule | some said letting it ring through |
| 22:58 | [acl] | interesting |
| 22:58 | detule | some said swiping ignore |
| 22:58 | [acl] | ill try that tonight. i havent been able to replicate lately |
| 22:58 | detule | again that's due to a JB addition |
| 23:00 | detule | here's a fellow who said he could do it on demand http://forum.xda-developers.com/showpost.php?p=21223202&postcount=91 |
| 23:02 | [acl] | looks like a sound routing night mare |
| 23:03 | [acl] | but we will have to try |
| 23:03 | [acl] | detule: anish on ppcg said the issue he had earlier went away with a csv swap. So not sure wtf to do with some of these reports |
| 23:04 | detule | with stock acoustic ten times out of ten my mic was not functioning on an incoming call when the device was in silent/vibrate |
| 23:05 | [acl] | exactly.. not sure what to make of these. I'll have to try all of this myself |
| 23:06 | detule | i mean acoustic before we turned the mic bias on |
| 23:06 | detule | always |
| 23:06 | detule | i don't think you've applied that mic hack in your tree |
| 23:06 | [acl] | you mean this one |
| 23:06 | [acl] | http://gitorious.org/xdandroid/hardware_msm7k/commit/5242c7bb6b930ff8af67cf6e613328dfef58316d |
| 23:06 | arrrghhh | nah i keep harassing him to |
| 23:07 | detule | yeah that one |
| 23:08 | arrrghhh | [acl], i have this problem at work all the damned time. user's just don't give the necessary amount of detail, or they go into detail on things that don't matter whatsoever. |
| 23:08 | [acl] | yeah just need emwe to add this for me so i can merge back fully .. https://github.com/acl/device_htc_rhodium/commit/f82bcf47a0348ca5b3b36c5c3f550d0ad9456535 |
| 23:08 | [acl] | arrrghhh: part of the prob is the libs arent compiled for true naggyness. So i may need to enable that |
| 23:08 | [acl] | it will spam the logcat |
| 23:09 | [acl] | showing every little nasty step |
| 23:09 | arrrghhh | naggyness |
| 23:09 | arrrghhh | nagginess? |
| 23:09 | arrrghhh | lol |
| 23:09 | arrrghhh | yea |
| 23:09 | arrrghhh | that'll cause logcat to wrap really quickly i'm sure... |
| 23:09 | [acl] | :-p |
| 23:09 | [acl] | lol |
| 23:09 | arrrghhh | can we increase that buffer, or have an option to log it to the SD? seriously. |
| 23:09 | detule | you need to train those nand boys to use getlogs |
| 23:10 | arrrghhh | hah |
| 23:10 | arrrghhh | good luck training them to do anything :P |
| 23:12 | [acl] | detule: you have to explain this to me |
| 23:12 | [acl] | http://gitorious.org/xdandroid/hardware_msm7k/commit/5242c7bb6b930ff8af67cf6e613328dfef58316d |
| 23:12 | [acl] | do yall compile with send_mic_mute_to_audiomanager ? |
| 23:12 | detule | no |
| 23:12 | detule | but i tested it that way too and it seemed to work |
| 23:13 | [acl] | hmm that kinda doesnt make sense |
| 23:13 | [acl] | lol |
| 23:13 | [acl] | damn android |
| 23:14 | detule | that's the calls from pressing the mute button in the in-call screen |
| 23:14 | detule | currently those get sent to the ril |
| 23:14 | detule | which apparently has the ability to mute the mic |
| 23:14 | [acl] | jebus |
| 23:15 | [acl] | ril can make sound decisions via kernel still ? |
| 23:15 | [acl] | or what do you mean ? |
| 23:15 | detule | no via AT commands |
| 23:15 | [acl] | ahh ok |
| 23:16 | [acl] | if compiled the other way, there is nothing going to libaudio? |
| 23:17 | detule | if compiled the other way everything goes to libaudio |
| 23:17 | [acl] | hmm sounds like more work :-p |
| 23:17 | detule | pick your poison RIL or acoustic |
| 23:17 | [acl] | i hate sound |
| 23:18 | [acl] | so i rather let the ril do its nonsense |
| 23:18 | detule | i understand both equally bad so i have little preference |
| 23:24 | [acl] | detule: ok dood. i gotta go. thanks for the help |
| 23:24 | detule | np, i don't think i told you anything you didn't know already |