Honestly would rather miss this one odd feature for a more simplified Pandora like Sound system that didn't eat CPU cycles dealing with volume control.
That's what we planned - and why the alternative chip even was implemented on earlier revisions.
However, the OMAP5 does not support any kind of a simple DAC like the OMAP3 does. The only way to use sound is the PALMAS... and that's where the driver has issues.
About the noise on the headset port: I can imagine something is actually interfering into the audio there.
As the PALMAS is near the SoC (it has to be, that's TIs setup), analog audio goes from near the SoC to the speakers and headset port as well.
Shielding it fully from interference would probably cost a few 10k EUR for going into a lab, doing measurements, changing the setup, etc.
That does not mean it can't be software though. We know the random audio crashes through the speakers can be totally disabled when the mic stream is disabled. It's not enough to mute the mic - disabling the stream is what's important.
Maybe something like this works here as well.
There are two important things to consider: There's software volume and hardware volume.
If the hardware volume is set to very low, it will pick up more noise as to when it's set to a high value.
So the hardware volume should be set to a high value and the software volume to a lower one.
I don't really know myself how this hardware / software should be setup properly, but I can imagine using the hardware codec will improve things a lot, as the hardware supports various effects (and probably also something like noise filtering)