I didn't save anything.

Here's the bottom line, if you're interested in it.

In the original Vibrant device directory there was a set of sources for libaudio -- one of the shared libraries that Android depends on to talk to the audio hardware in the phone. There was no documentation as to where this source came from, but I know where it didn't come from -- it didn't come from a public Gingerbread source for the Vibrant, because there isn't one.

It turns out the library this source builds does not work correctly but exactly why I'm not certain of. One of the problems with debugging this is that I have to have someone else test for me, which means I can't do the sort of testing I like to when I'm tracing things like this (a highly-iterative process that requires that I actually be staring at the debugging screen while doing the deeds that cause the bad behavior) since I can't call 911 myself.. Had the provenance of this code been documented originally (or lack thereof) I would have investigated this possible connection, as I knew the problem lay in the audio connectivity due to myriad kernel and application traces a couple of months ago. I didn't chase that library down and attempt to graft in other related versions because I assumed that the CM people knew what they were doing building that library from source rather than using a cribbed copy from, for example, Froyo or a different gingerbread build off a similar device.

Picking up a different shared library does work. Exactly what the provenance of that library is (e.g. was it grabbed from a binary, was it built from DIFFERENT source, where did it come from?) is also unknown.

Now that I have a working shared library on this device and a non-working one I'm going to compare traces. Maybe I'll get lucky and find the changes necessary in the source that's in the build tree and be able to fix that, at which point I'll know what I've got rather than having a "magic" library from God-knows-where.

Now here's the part that annoys me -- I was all over some of the CM guys about audio problems with other Samsung devices and tried to get access to the "not yet finished" repos because I expected that if I could run down the same sort of problem with ordinary calls in one of the OTHER Samsungs it was rather more likely than not that the same fix would be pertinent in some way on the Vibrant -- simply because manufacturers tend to use the same chipsets and bits, along with APIs, between different devices (it makes it easier for their coders and maintainers to do their jobs.) In addition when I started working one this one of the other protagonists didn't give me jack and crap about the provenance of anything in the device tree and, again, there's no docs embedded in the tree either. You can find the flamewar and slander aimed at me here if you'd like. It turns out I was on the right path; the problem this library allegedly fixed was having to hit <MUTE> twice to turn off and on the audio path. Sound familiar? Well, the pointer to the file that I found and integrated was from a bug logged against the I-9000, a similar phone to the Vibrant, and that library version works. What's changed in it? There's no set of commits logged against the ZIP file provided in that patch; is it a binary lift from a different build (e.g. some factory build) or did someone fix the source?

Who the hell knows because again, it's not documented in the bugtracker. Until I know where it came from and, if there's source, I have access to it, I won't support it. I don't play the "hide the sausage" game when it comes to alleged community coding projects.

I ran into something similar with the Triumph in that there was a different set of parameters coming up from the hardware when a wired headset was plugged in. That was easy to run down because I could do it and see what was going on; it was a literal couple of line change in the code once I found it. There are a couple of places in the libaudio source that might be the cause of this now that I have a reason to look in there, but without being able to easily reproduce the condition that creates the failure (e.g. call 911) it's a guess.

The ICS builds out at present have a different copy of the same compiled library and it also works. I bet that one works too on CM7 as it's fairly close to the metal and thus the API's probably the same (or close) on the Android side but I haven't tried it yet. I've got little reason to since I now have a libaudio.so that's functional on CM7 in any event.

While I've been working on the 911 issue (for a couple months on and off) I also traced down some actual working (properly) GPS libraries that handle the AGPS assist data in the correct way, something that other sets of them do not, and added those too. I also made a few other changes. The battery life is reported to be rather impressive, and the near-instant GPS locks most-definitely are. I can't speak much to the battery life view of the world as of yet but I will be looking at that; that's an area I know quite a bit about (getting these devices to properly go into deep sleep as they should) and the source tree I'm working with does have kernel source.

Any sideloaded kernel that leaves libaudio.so alone (check the zip file to make sure that /system/lib/libaudio.so is NOT present) should be ok, but no promises. Before you go screwing with kernels make sure you want to --you might break GPS performance as a number of the kernels have various attempts to get the GPS to work right and load various libraries along with the kernel itself with varying degrees of success.

I'd be willing to maintain this port but there are two conditions -- first, I expect apologies from the CM people who attacked me, in public, and second, I expect a formal commitment that there will be no more hiding of information. "I don't know" is an acceptable answer provided you run down the person who does -- someone does know because someone DID either import or code the material in question; silence and lack of documenting where things came from and how they came to be is not acceptable. When things go into the codebase through review they damn well ought to be documented. I played "talking to the brick wall" with the Triumph and now the Vibrant and I won't do it if I'm taking on responsibility for maintaining something.

If CM wants me involved in this that's the deal. If not I'll consider setting up a parallel build and set of repos for the bits that have to be changed from the base CM7 Gingerbread branch as I did for the Triumph if there are people interested in it, but my time is not unlimited and in all honesty my taste for working with the CM people and the CM code in general has been seriously damaged, never mind that what I have here seems to work just fine. As such the benefits of continued efforts are likely to be relatively small. If I decide against a continuing effort I will take the build environment that produced that I have now and attempt to set up a manifest so it can be cloned by anyone else who cares to do so, which should take care of others being able to build and run the KANGs from source if they wish. The latter may take a while as I need to find a day when I'm not busy and can put that together (again, lack of documentation doesn't help) and then pull a clean test from a zero base and make sure it builds and runs.

The Vibrant is no longer my daily device but I do still own one, and given its relatively modest resale value I'll probably keep it as a spare device -- it's a very credible phone and with working GPS code it actually locks faster and better than my Hercules does. It's biggest shortcoming is that it's relatively RAM-starved compared to more-modern devices.

Fancy that.
Investing? http://market-ticker.org
Looking for me? http://www.denninger.net
T-Mobile and Virgin