[HTC One V] robaho:
Yes. Even flashed the kernel from the 11/04 in case something changed. I can do the entire process again if you would like.

Again. VM USA.

Let me know what you need.

---------- Post added at 10:22 AM ---------- Previous post was at 10:13 AM ----------

As for the bluetooth voice audio issue, I think these may be the relevant entries from the logcat:

D/Bluetooth HSHFP( 461): AudioStateIntent: 00:1A:7D:35:55:BE State: 12 PrevState: 11

D/AudioHardware7x30( 106): setVoiceVolume(0.800000)

I/AudioHardware7x30( 106): Setting in-call volume to 80 (available range is 0 to 100)

I/HTC Acoustic( 106): update voice ACDB id: (tx_acdb, rx_acdb) = (105, 205)

I/HTC Acoustic( 106): update voice ACDB id (105, 205) success

I/AudioHardware7x30( 106): update_voice_acdb(105, 205) succeeded

D/AudioHardware7x30( 106): setVoiceVolume(1.000000)

I/AudioHardware7x30( 106): Setting in-call volume to 100 (available range is 0 to 100)

I/AudioHardware7x30( 106): Routing audio to Bluetooth PCM

D/Tethering( 316): MasterInitialState.processMessage what=3

D/PicasaUploaderSyncManager( 1055): active network: null

D/PicasaUploaderSyncManager( 1055): background data: true

D/AudioHardware7x30( 106): AudioStreamOutMSM7x30::standby()

D/AudioHardware7x30( 106): Deroute pcm out stream

E/AudioHardware7x30( 106): updateDeviceInfo: E rx_device 17 and tx_device 18

D/AudioHardware7x30( 106): case VOICE_CALL

E/AudioHardware7x30( 106): updateDeviceInfo: X cur_rx 17 cur_tx 18

When it is re-routing the pcm out stream, it is getting errors updating the device info.

---------- Post added at 10:30 AM ---------- Previous post was at 10:22 AM ----------

Also, here are the logcat entries when attempting to send the MMS:

D/Tethering( 316): MasterInitialState.processMessage what=3

V/TransactionSettings( 948): APN setting: MMSC: http://mmsc.vmobl.com:8088/mms? looked for: current IS NOT NULL

D/ConnectivityService( 316): startUsingNetworkFeature reconnecting to 0: enableMMS

D/PicasaUploaderSyncManager( 1055): active network: NetworkInfo: type: mobile[CDMA - EvDo rev. A], state: CONNECTED/CONNECTED, reason: 2GVoiceCallEnded, extra: , roaming: false, failover: false, isAvailable: true

D/PicasaUploaderSyncManager( 1055): background data: true

D/ConnectivityService( 316): handleInetConditionHoldEnd: net=0, condition=100, published conditio

---------- Post added at 10:43 AM ---------- Previous post was at 10:30 AM ----------

One other thing:

I notice that the GC concurrent pause times are an order of magnitude higher than say JmzOneV running the sickkernel.

With Evervolv, I am seeing

D/dalvikvm( 316): GC_FOR_ALLOC freed 3344K, 36% free 10212K/15943K, paused 67ms, total 71ms

D/dalvikvm( 384): GC_CONCURRENT freed 1111K, 45% free 6248K/11207K, paused 20ms+12ms, total 91ms

D/dalvikvm( 316): GC_CONCURRENT freed 632K, 28% free 11593K/15943K, paused 13ms+6ms, total 73ms

And with the JmzOneV/sick

D/dalvikvm( 919): GC_CONCURRENT freed 1714K, 26% free 5437K/7267K, paused 1ms+3ms

D/dalvikvm( 320): GC_CONCURRENT freed 2139K, 16% free 12176K/14435K, paused 3ms+7ms

D/dalvikvm( 919): GC_CONCURRENT freed 1741K, 26% free 5472K/7331K, paused 1ms+4ms

D/dalvikvm( 320): GC_EXPLICIT freed 425K, 16% free 12133K/14435K, paused 4ms+9ms

I see