[HTC Vivid, Raider, Velocity] homeslice976:
I'm also testing a theory right now based on reverting this (https://github.com/Sportsstar89/and...mmit/9261a3aab974db0a376d3a398e4302e6ba53ca76) and this (https://github.com/Sportsstar89/and...mmit/56d56f55bf08dd25295bd93ae40b2df78ec30f52) (but leaving the att in call audio fix alone)

Comparing to HTC's sources (which could very possibly be very incomplete), these changes weren't there (obviously, or else they wouldn't be changes). Of course, we didn't have ATT in call audio with HTC's sources either. In the first commit, htc acoustic table values are directed to new sources (.csv files). In ATT's source, both audience and non audience were directed to aic3254 txt files. I'm thinking, since my previous "audiofix" which played with some TPA2051 values seemed to improve other audio, maybe these dsp .csv configs are only for non-call audio, and the in call audio requires a the aic .txt files? With the second commit - again, in HTC's source, they didn't have any indicators for ATT SKU 1 or ATT SKU 2, just ATT SKU3 had support_audience=1. What if not all of the ATT Vivid's have the audience chip? Only a select batch.(Edit: New theory for this is the support_audience=1 that was listed is actually defined for all 3 ATT SKU's, and the other entry "Default" is for the other models. So it's possible that the in call mic always worked if you screamed in it for ATT users, but maybe no one ever tried?) IFFFFF these theories were to pan out - it would possibly explain why some have echo and some don't, why in call audio seems worse for some people (and can't be adjusted), and possibly even why some ATT users have no trouble with in call audio on the first try, and others do. All theories though. h8rift seems like a smart dude, so chances are reverting these changes won't help a bit. But honestly, the ratio of things I've done that haven't worked/things I've fixed is like 200/3, so I won't be disappointed if nothing happens :)

Edit: Also - in HTC's sources "int vol = 0" as well

Edit: Well audio did initialize on the first call after flashing the new kernel and rebooting. Also rebooted again after that to test, and in call audio kicked in on the first call again. In the past after any kind of reboot, first call didn't work. Audio adjustment still doesn't work. I'll call my wife shortly to see if the echo still exists. But this appears to have at least killed the first call audio not working bug. If anyone else wants to test here you go:

zImage and bcmdhd.ko are here (https://docs.google.com/folder/d/0B8HUFb41pK2eQjFZMWx6UE43VnM/edit)

Don't know about other recoveries, but with WCX, in Developer Options, you can make and flash boot from zImage. Follow on screen instructions. maybe someone else can make a boot.img and I'll make a flashable package.

Edit 2: Still echoes on remote end. Slightly, but it's there. I don't know how bad it was before though - didn't try it for myself til now. Also my wife just said it still echoes, but it's not as bad. Please test and post results (in which case I have a few other thoughts as well, but I'm going to lunch now :))

The couple of calls I had over lunch said there wasn't any echo. Anyone give this a go yet?