Delay when answering/placing calls post 4.3

Search This thread

thedumbass

Member
Oct 20, 2010
37
3
Turned out CNexus' suggestion of disabling noise filtering made things bearable for me. The issue is still there but not anywhere near as noticeable. Had it not been worse before, I might not have noticed how it is now.
 

metalfan78

Senior Member
Jan 30, 2010
5,009
2,476
Littleton, CO
My wife took the OTA on her s3 and she doesn't have any issues. I thought about going stock and taking the OTA, or using Odin to flash it but I can't bring myself to 'knox' my phone.
 

decimalman

Senior Member
Nov 3, 2012
1,259
3,614
TL;DR: I'm working on fixing this. The work I've done recently is rolled up in this kernel, and it sounds like it's helping with at least one person's issues.

I suspect this is a collection of major kernel bugs caused by the new Sprint a2220 (voice processor) firmware (or lack thereof). As far as I can tell, the problem basically boils down to this: the dialer is trying to configure the a2220 incorrectly and causes a bunch of errors; instead of recovering gracefully, the driver completely resets the chip, which typically takes between 5 and 15 seconds. The dialer (and the person at the other end of the call) have to wait for the chip to reboot before the call can properly begin.

There's at least two issues at play here: kernels don't pull in the correct firmware and the a2220 driver absolutely sucks. I fixed the firmware issue a while back (this commit), and I'm currently working on completely rewriting the driver (it's beyond saving) to handle error conditions better and not cause them as often.

If anyone is feeling adventurous, I'd appreciate help testing the new driver. Any feedback (helps? doesn't? crashes?) would be helpful.

EDIT: There's a new, better-behaved build here.
EDIT 2: My changes are merged into my kernel, available here.
 
Last edited:
  • Like
Reactions: remotehugger

remotehugger

Senior Member
Mar 5, 2012
1,498
788
DeWitt
Just wanted to put this out there - I am running this new kernel by @decimalman and so far so good - it has drastically improved the dialer lag and I have had much better sound quality during calls with noise reduction active - I'm on a VM S3 running the MK5 build of 4.3 TW by @jdsingle76 -

From my GSIII - jd's Stock/Rooted/Deodexed 4.3
 
  • Like
Reactions: jdsingle76

decimalman

Senior Member
Nov 3, 2012
1,259
3,614
So what you're basically saying is that Samsung screwed the pooch?

Not at all. I'm saying that Samsung is playing fast and loose with the GPL. The MK3 kernel source contains any number of tricks to keep it from building correctly unless Samsung is building it themselves. Without patching it, exFAT support is (silently) skipped, the a2220 driver uses AT&T's firmware instead of Sprint's, and there's likely a few more bugs affecting the a2220 and video drivers (and possibly others as well).

EDIT: To clarify, some of the source code uses magic #define macros and directory layouts in order to change how it's built. Without being built by Samsung's build tree, that magic is missing and the resulting kernel isn't functionally equivalent to the kernel Samsung provided. GPLv2 doesn't explicitly forbid this, so they're technically compliant.
 
Last edited:

CNexus

Senior Member
May 17, 2012
9,010
14,000
~/android
Google Pixel 7

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    So what you're basically saying is that Samsung screwed the pooch?

    Not at all. I'm saying that Samsung is playing fast and loose with the GPL. The MK3 kernel source contains any number of tricks to keep it from building correctly unless Samsung is building it themselves. Without patching it, exFAT support is (silently) skipped, the a2220 driver uses AT&T's firmware instead of Sprint's, and there's likely a few more bugs affecting the a2220 and video drivers (and possibly others as well).

    EDIT: To clarify, some of the source code uses magic #define macros and directory layouts in order to change how it's built. Without being built by Samsung's build tree, that magic is missing and the resulting kernel isn't functionally equivalent to the kernel Samsung provided. GPLv2 doesn't explicitly forbid this, so they're technically compliant.
    2
    Yup, what he said could not be more spot on...


    For example, take a look at my commit here: https://github.com/cnexus/kernel_tw_43/commit/75f9e924c28a9d88cfe9b9c9b477c0c68621a87a

    That line that I removed was originally only pulling in exfat if some folder way up in Samsung build tree exists. And so, since we don't have the same build setup as Samsung, exfat gets skipped unless you remove that
    1
    So far my calls have been much better after using Odin to go back to stock md4. I'm wary of flashing mk3 now.

    Yeah I've never had a problem with stock MD4. Sadly I really like 4.3 and would hate to have to go back. Anyone have a link to just a stock fully functional MK3 modem I can try and force in through odin? I'm pretty green on this stuff but it's obviously just the modem that has an issue...or am I wrong here?
    1
    TL;DR: I'm working on fixing this. The work I've done recently is rolled up in this kernel, and it sounds like it's helping with at least one person's issues.

    I suspect this is a collection of major kernel bugs caused by the new Sprint a2220 (voice processor) firmware (or lack thereof). As far as I can tell, the problem basically boils down to this: the dialer is trying to configure the a2220 incorrectly and causes a bunch of errors; instead of recovering gracefully, the driver completely resets the chip, which typically takes between 5 and 15 seconds. The dialer (and the person at the other end of the call) have to wait for the chip to reboot before the call can properly begin.

    There's at least two issues at play here: kernels don't pull in the correct firmware and the a2220 driver absolutely sucks. I fixed the firmware issue a while back (this commit), and I'm currently working on completely rewriting the driver (it's beyond saving) to handle error conditions better and not cause them as often.

    If anyone is feeling adventurous, I'd appreciate help testing the new driver. Any feedback (helps? doesn't? crashes?) would be helpful.

    EDIT: There's a new, better-behaved build here.
    EDIT 2: My changes are merged into my kernel, available here.
    1
    Just wanted to put this out there - I am running this new kernel by @decimalman and so far so good - it has drastically improved the dialer lag and I have had much better sound quality during calls with noise reduction active - I'm on a VM S3 running the MK5 build of 4.3 TW by @jdsingle76 -

    From my GSIII - jd's Stock/Rooted/Deodexed 4.3