yashsingh1/xdaforums huggingface dataset:
[HTC Rezound] Jonman409:
Awesome man, thanks again. Worked 100% first try.

---------- Post added at 02:21 AM ---------- Previous post was at 02:19 AM ----------

Eh if it helps out the community it's no biggie. Besides, I have about 5 Motorola omap3's that are running a custom ICS build right now so I can always just run one of those for a while if I brick it.
[HTC Rezound] TheBr0ken:
Could be kernel, but also looks like some changes needed to he made in Android_hardware_qcom_audio to get things working right on the Pyramid. Haven't dug deep into this yet, just an idea -> https://github.com/bruce2728/androi...mmit/5d14c13e59dbcdb8f90a3a23d1c73d17c9c049ca

Figuring since aosp was brought to us using the Pyramid as a reference there might be something there. BTW, Bruce2728 seems to know what he's doing with the Sensation. So might be some more good stuff in there to look at.
[HTC Rezound] Snuzzo:
Going to try and build an AOKP ICS rom using his qcom/audio and see where that gets me.
[HTC Rezound] TheBr0ken:
Not sure what or if there are any dependencies missing from our tree, but it wouldn't build in jb. Again, I didn't spend too much time with it. Might have also been user error too, who knows
[HTC Rezound] Snuzzo:
Mine also errors out. I don't really have the time to look into it further unfortunately. =/
[HTC Rezound] TheBr0ken:
Well I did notice that chad forked his media repo, so its very possible that he will eventually look at his audio repo to see if there is anything useful in there.
[HTC Rezound] dlumberg:
It looks like he did a lot of code cleaning and added some stuff. I'm building right now with the changes, we'll see if it finishes.
[HTC Rezound] TheBr0ken:
It errored out for me. Didn't have too much time to mess with it though
[HTC Rezound] dlumberg:
CCACHE errored out for me so I did a make clobber... it looked like it already went through the audio folder but I'm not saying anything until it finishes.

So it looks like he took out all of the #if HTC_ACOUSTIC stuff (presumably because Samsung stopped using this board???) and changed some of the ALOGs and generally cleaned up the code. I saw a few new blocks of code in there and also some new device definitions. There were also quite a few minor changes to a lot of the functions.

If it doesn't build then I'll take a closer look at everything tonight at some point and report back.
[HTC Rezound] kkozma:
I tried to get it to build CM10 and it also wouldn't build. I pulled his msm8660_common as well and tried to build. I went from about 100+ errors down to 1 or 2. Figure I'd try a make clobber and see what happens but I'm not convinced it's going to be any different.

If anyone's interested this is the error.

::AudioHardwareInterface* android_audio_legacy::createAudioHardware()':
hardware/qcom/audio/msm8660/AudioHardware.cpp:4524:30: error: cannot allocate an object of abstract type 'android_audio_legacy::AudioHardware'
hardware/qcom/audio/msm8660/AudioHardware.h:140:7: note: because the following virtual functions are pure within 'android_audio_legacy::AudioHardware':
hardware/libhardware_legacy/include/hardware_legacy/AudioHardwareInterface.h:347:29: note:	virtual android_audio_legacy::AudioStreamOut* android_audio_legacy::AudioHardwareInterface::openOutputStream(uint32_t, audio_output_flags_t, int*, uint32_t*, uint32_t*, android::status_t*)
make: *** [/home/vwmofo/android/cm10/out/target/product/vigor/obj/SHARED_LIBRARIES/audio.primary.msm8660_intermediates/AudioHardware.o] Error 1
[HTC Rezound] shrike1978:
AudioHardwareInterface is being passed the wrong number of arguments. There's not a definition for the class with that number of arguments, so the compiler is treating it as a different function and failing. AudioHarwareInterface likely needs an explicit override for that argument set.
[HTC Rezound] kkozma:
Excellent, well the build is running now so I suspect it'll fail.

I'll take a look at that once it's done.

*EDIT: The make clobber resulted in more errors. *sigh* It looks like CM made changes to AudioHardwareInterface after the changes that Bruce made, so my guess is that whatever they did broke it.
[HTC Rezound] TheBr0ken:
I might just sync with Bruce's manifest and see if it builds for the pyramid. If it does I'll add the vigor tree and try and build again, if it fails then I know its the device tree and not cm. My guess is that were missing some dependencies needed by cm. Though that still doesn't guarantee a fix for BT
[HTC Rezound] dlumberg:
What are the output files for AudioHardware? Has anyone tried copying over the compiled files to the Rez?
[HTC Rezound] kkozma:
I found a code mistake, or at least what looks like a mistake to me in hardware/qcom/audio/msm8660/audio_hw_hal.cpp in function adev_open_output_stream

Before:

out->qcom_out = qadev->hwif->openOutputStream(devices,

(int *)&config->format,

&config->channel_mask,

&config->sample_rate,

&status);

After:

out->qcom_out = qadev->hwif->openOutputStream(devices, flags,

(int *)&config->format,

&config->channel_mask,

&config->sample_rate,

&status);

I also removed the pure declaration from function AudioStreamOut* in AudioHardwareInterface.h.

It looks like it might build, but I've been fooled before! haha
[HTC Rezound] Snuzzo:
Here's mine taken from AOKP ICS builds

out->qcom_out = qadev->hwif->openOutputStream(devices, format, channels,
sample_rate, &status);

Very similar to what you have there and non working BT in call audio as well.
[HTC Rezound] kkozma:
Well, I got it to build! WOOT. Going to flash it now and I'll report back.
[HTC Rezound] GrayBoltWolf:
It's a great feeling right?
[HTC Rezound] kkozma:
Indeed it is. It would be greater if it worked. :(

Although I dirty flashed it, so that might have something to do with it. Don't have time to reflash right now. I'll try again later.
[HTC Rezound] kkozma:
Clean flash didn't work either. :(

Back to the drawing board I guess.
[HTC Rezound] hceuterpe:
BT Headset Audio

Kernel driver file here->vigor_aosp_kernel / arch / arm / mach-msm / board-vigor-audio.c

(line)

void vigor_snddev_bt_sco_pamp_on(int en)

{

/* to be implemented */

}

Only pamp_on function that has nothing.

Line 366:

static struct q6v2audio_analog_ops ops = {

...

.bt_sco_enable	= vigor_snddev_bt_sco_pamp_on,

...

};

Line 388:

static struct q6v2audio_ecodec_ops eops = {

.bt_sco_enable = vigor_snddev_bt_sco_pamp_on,

};

Original HTC config file has CONFIG_BT_SCO is not set

We have CONFIG_BT_SCO=y

CONFIG_MACH_VIGOR=y

->obj-$(CONFIG_MACH_VIGOR) += board-vigor-audio.o

Is this why Bluetooth audio doesn't work right?
[HTC Rezound] Snuzzo:
Already tried with sco disabled.

Sent from my ADR6425LVW using Xparent Red Tapatalk 2
[HTC Rezound] hceuterpe:
Is there any historical code from that? Also isn't SCO required for Bluetooth headset profile?
[HTC Rezound] kkozma:
I figured I'd at least try to route the speakerphone to BT Audio and use the handset mic so you could at least hear the phone conversation in the car. Broke BT audio in the process. GRRR

*sigh*
[HTC Rezound] hceuterpe:
What if we inject the Nexus One BT code from the Kernel driver:

http://photon-android.googlecode.co...on_nightly/arch/arm/mach-msm/board-mahimahi.h

/* Bluetooth PCM */

#define MAHIMAHI_BT_PCM_OUT	68

#define MAHIMAHI_BT_PCM_IN	69

#define MAHIMAHI_BT_PCM_SYNC	70

#define MAHIMAHI_BT_PCM_CLK	71

http://code.google.com/p/photon-and...rch/arm/mach-msm/board-mahimahi-audio.c?r=129

void mahimahi_bt_sco_enable(int en)

{

static int bt_sco_refcount;

D("%s %d\n", __func__, en);

mutex_lock(&bt_sco_lock);

if (en) {

if (++bt_sco_refcount == 1)

config_gpio_table(bt_sco_enable,

ARRAY_SIZE(bt_sco_enable));

} else {

if (--bt_sco_refcount == 0) {

config_gpio_table(bt_sco_disable,

ARRAY_SIZE(bt_sco_disable));

gpio_set_value(MAHIMAHI_BT_PCM_OUT, 0);

}

}

mutex_unlock(&bt_sco_lock);

}

Can't tell if the GPIO numbers match, but those 4 are not defined anywhere. Also 68-71 appears to commonly be used for BT audio on multiple other HTC phones from earlier models...
[HTC Rezound] kkozma:
Well, I don't know anything about the kernel stuff, but what I do see there that's interesting is the reference to PCM. I know I saw somewhere that SCO was defaulted to HCI.
[HTC Rezound] hceuterpe:
One X has something very similiar:

https://github.com/htc-mirror/evita.../master/arch/arm/mach-msm/board-elite-audio.c

#define GPIO_AUX_PCM_DOUT 63

#define GPIO_AUX_PCM_DIN 64

#define GPIO_AUX_PCM_SYNC 65

#define GPIO_AUX_PCM_CLK 66
[HTC Rezound] dlumberg:
That's a msm8960 board, the entire .c file is completely different :(

Also, digging through the kernel files I tried disabling beats capability just to see if it was somehow looking for that and there was no change.
[HTC Rezound] kkozma:
When I was messing around with trying to at least route the speakerphone audio to A2DP yesterday (which completely failed sadly), I did make a few changes to AudioPolicyManager under the BT SCO section and for a short instance I was able to very faintly hear myself, but it quickly disappeared.

I changed the code from: AudioSystem:: DEVICE_OUT_BLUETOOTH_SCO_ blah blah

to AUDIO_DEVICE_OUT_BLUETOOTH_SCO_ blah blah

I would still really like to know where the enumeration is for the ALSA Device ID's so we can figure out what ALSA Dev ID: 37 & 38 are. That might at least point us in the right direction. If we know what it's trying to connect to, we can take a look at the code for those devices. Does anyone know where those definitions are? I'm thinking they must be in the kernel somewhere, but I'll be damned if I can find them.
[HTC Rezound] puhleez:
Last time I tried to test BT, I am called myself (to get vm) and the call started with a bunch of white noise, then I could hear the greeting with the static and then the greeting faded out over the course of a few seconds. Makes me think that the devices are connected but the data stream is getting corrupted somehow. Possible that multiple devices are connected?
[HTC Rezound] dlumberg:
I always call comcast, their robot lady must be getting sick of me :laugh:

I'm guessing it's set in vidor-3.0/include/sound/asound.h
[HTC Rezound] kkozma:
I call my work phone. lol

Ok, it's not in asound.h. I found some definitions in apr_audio.h

#define INT_BT_SCO_RX 0x3000	/* index = 25 */
#define INT_BT_SCO_TX 0x3001	/* index = 26 */
#define INT_BT_A2DP_RX 0x3002	/* index = 27 */

I'm not sure on that conversion though. Converting to Decimal doesn't come anywhere near 37 or 38.
[HTC Rezound] hceuterpe:
I'm aware the 8960 is a different board, but there is still reference to the 4 BT PCM GPIOs
[HTC Rezound] TuxDroid:
Thinking about this as a bunch of text files just like I'd see on one of the systems I administer, have you tried a recursive grep of the entire source tree?
[HTC Rezound] dlumberg:
Here's a grep of the kernel tree for BT case sensitive.
[HTC Rezound] TuxDroid:
If someone can tell me where to sync the code from I will be happy to run a few more searches to try and track it down... assuming the hunt is still on.
[HTC Rezound] dlumberg:
Welcome to the fun!!!

repo init -u git://github.com/Chad0989/android.git -b jellybean

That will bring in the entire CM10 repo, after building it's about 30GB.
[HTC Rezound] erishasnobattery:
I still stick to my previous suggestion that the issue is not with the routing. As evidenced by the occasional sounds we do get, I believe its going where it should.

I believe the problem is with the buffering of the PCM playback. For whatever reason, not enough is being put into the buffers, hence the partial playback.

I'm no kernel dev though, so it's just my. 02

Sent from my Galaxy Nexus
[HTC Rezound] dlumberg:
I agree that it's probably not routing, my running theory is noise cancellation or gain (because of the fuzziness in the sound before it goes away) triggering something that mutes the stream. The problem is most likely in fixed in CM code though because the same kernel code will work with a sense rom..
[HTC Rezound] kkozma:
Ok guys, I think I've found something but I don't know nearly enough about it to just blindy try without some guidance... I was reading through bruces thread for his CM10 rom for the Sensation. He noted that he used the device code from someone named intervigilium. Anyhoo. I took a look at his git and there's a quite a bit in there for the msm8660 (device, hardware, & kernel) and there are SEVERAL commits regarding BT in the last few days. The kernel changes look to be most promising. Can I just cherry pick some stuff out of there? What's safe to try and what isn't?

Take a look for yourselves. https://github.com/intervigilium

Here's a look at all the commits "Fix BT for AOSP" : https://github.com/intervigilium/an...mmit/18281ee40b1adf41bd4ae4cc0479759bbe1ebc65
[HTC Rezound] Snuzzo:
I'll try it real quick kkozma. Should only take a few moments.
[HTC Rezound] Snuzzo:
Bluetooth now does not even turn on. =/

Pushed the changes here for someone else to look at also

https://github.com/Snuzzo/vigor_aosp_kernel/commits/bt-test

https://github.com/Snuzzo/vigor_aosp_kernel/commit/bd91b3d0b08c5b47f34cf208cdc103ab50c64408

https://github.com/Snuzzo/vigor_aosp_kernel/commit/004aea601cb2587628224012b1e3e8e578c9e481

https://github.com/Snuzzo/vigor_aosp_kernel/commit/d3dcac425f1b529bd3127ab8f8f50a1c8ac4ed4d
[HTC Rezound] kkozma:
Damnit. Well, thanks for trying... I may play around with it myself as well....
[HTC Rezound] Snuzzo:
Don't worry, still working on it.
[HTC Rezound] kkozma:
I also noticed his qcom_hardware_audio and msm8660_common were newer in the last few days as well so I cloned that and got it to build. I'll report back later if there's any change.
[HTC Rezound] kkozma:
BT wouldn't turn on with that stuff either. :( One brick wall after another.
[HTC Rezound] dlumberg:
I tried manually applying this commit to the vigor Kernel and there was no change.

Edit: I probably should have looked at this first:
[HTC Rezound] TuxDroid:
Can someone who has the build installed please do an adb shell and post the output of

cat /proc/asound/*
[HTC Rezound] kkozma:
shell@android:/ $ cat /proc/asound/*
cat /proc/asound/*
/system/bin/sh: cat: /proc/asound/card0: Is a directory
0 [msmaudio ]: - msm-audio
msm-audio
0: [ 0] : control
16: [ 0- 0]: digital audio playback
24: [ 0- 0]: digital audio capture
33: : timer
/system/bin/sh: cat: /proc/asound/msmaudio: Is a directory
00-00: DSP 1 msm-codec-dai-0 : : playback 2 : capture 1
G0: system timer : 10000.000us (10000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE
P0-0-1: PCM capture 0-0-1 : SLAVE
P0-0-2: PCM playback 0-0-2 : SLAVE
Advanced Linux Sound Architecture Driver Version 1.0.24.
[HTC Rezound] TuxDroid:
So, I have been looking for info about id:37 and id:38 and found a bit of info. in ALSA-Configuration.txt I found this:

Now that I know 37 and 38 are not indexes (too high a number) I started looking at the other part of those lines from logcat and noticed that maybe the indexes are for #'s 17-18. Upon looking for those, I found this:

kernel/htc/vigor-3.0/include/sound$ grep --color=always -R -i -e "index = 1[7-8]" ./ 2>/dev/null
./apr_audio.h:#define SLIMBUS_1_RX	0x4002	/* index = 17 */
./apr_audio.h:#define SLIMBUS_1_TX	0x4003	/* index = 18 */

What are your thoughts? Is this helpful or did I take off down a useless road?
[HTC Rezound] kkozma:
So the more I think about this, it looks more and more like a routing issue and my logcat really seems to support that theory. Device 17 & 18 were connected and enabled. Then as soon as the call came in they were disabled. Certainly explains the momentary bit at the beginning where it does work.
[HTC Rezound] TuxDroid:
This was the same conclusion I came to after reading your post. Did you see anything where 17&18 worked correctly during a non-BT call? I ask as a means of narrowing down if it's a routing issue or an issue with those two.
[HTC Rezound] dlumberg:
tpa2051 is the amp driver for the speakers on the phone.

I checked into it and it's getting passed this

device/htc/msm8660-common/include/linux/tpa2051d3.h:#define TPA2051_IOCTL_MAGIC 'a'

into this

device/htc/msm8660-common/include/linux/tpa2051d3.h:#define TPA2051_SET_MODE _IOW(TPA2051_IOCTL_MAGIC, 0x03, unsigned)

and this is throwing the error

hardware/qcom/audio/msm8660/AudioHardware.cpp~: ALOGE("ioctl TPA2051_SET_MODE failed: %s", strerror(errno));

but according to this the first arg should be an integer and not a string.... could be something... dunno
[HTC Rezound] MaulingDeOso:
Nah, it's perfectly normal for a character to represent a value, particularly when as a "magic" string. The reason it's failing is the third argument: add a stack dump there and look into why the mode being passed is invalid.
[HTC Rezound] dlumberg:
You might be on to something... I noticed that further down in the apr_audio.h

#define INT_BT_SCO_RX 0x3000	/* index = 25 */
#define INT_BT_SCO_TX 0x3001	/* index = 26 */

I tried changing

static const uint32_t DEVICE_BT_SCO_RX = 25; //bt_sco_rx
static const uint32_t DEVICE_BT_SCO_TX = 26; //bt_sco_tx

in AudioHardware.cpp without any luck but if there's other references where they are 25 and 26 and not 17 and 18 they could be causing a routing issue....

I'm gonna try compiling with apr_audio.h set to 17 and 18 to see if that changes anything...
[HTC Rezound] Flyhalf205:
Any luck guys? On CM10. I was able to get audio coming over bluetooth for my 1st call. 2nd would not work anymore. CM9 I still can't get anything.

Update: CM10 Bluetooth connects at first with static audio but starts fading to no audio. It's a start at least.
[HTC Rezound] dlumberg:
It comes back for a second if you wait long enough, then fades out again.
[HTC Rezound] Snuzzo:
Any luck on the build with modified routing? :)
[HTC Rezound] dlumberg:
No luck. I'm looking into the acdb stuff, from what I can tell there seems to be a constant related to acdb-loader stuff and GAIN that shows up in logcat but I can't find any instance of it getting set in the kernel code...
[HTC Rezound] Snuzzo:
Post up the logcat. Working on a project now but others would probably like to see it.

Sent from my HTC Rezound using Xparent ICS Tapatalk 2
[HTC Rezound] Flyhalf205:
Well this is interesting. CM9 audio was completely silent for me on stock build. I played around and now got it to the same result as CM10. The audio is static and then fades out.

After making a call. My Mic is staying on and can hear everything amplified through my handset earpiece lol

I am seeing. E/AudioHardwareMSM8660( 134): unknown stream Could be that

D/AudioHardwareMSM8660( 134): value of device and enable is 0 0 ALSA dev id:0
D/Bluetooth HSHFP( 510): AudioStateIntent: 00:13:17:5B:8E:E5 State: 12 PrevState: 11
D/AudioHardwareMSM8660( 134): value of device and enable is 1 0 ALSA dev id:1
D/Sensors ( 253): Enabling Proximity Sensor..., mEnabled = 1, new state = 0
D/Sensors ( 253): Enabling Proximity Sensor..., mEnabled = 0
D/AudioHardwareMSM8660( 134): value of device and enable is 17 1 ALSA dev id:37
D/AudioHardwareMSM8660( 134): value of device and enable is 18 1 ALSA dev id:38
D/AudioHardwareMSM8660( 134): updateDeviceInfo: X
D/AudioHardwareMSM8660( 134): write(): dec_id = 1 cur_rx = 17
V/AudioHardwareMSM8660( 134): cur_rx for pcm playback = 17
D/AudioHardwareMSM8660( 134): value of device and enable is 17 1 ALSA dev id:37
D/ACDB-LOADER( 134): ACDB -> send_audio_cal, acdb_id = 22, path = 0
D/ACDB-LOADER( 134): ACDB -> send_audtable
D/ACDB-LOADER( 134): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TABLE
D/ACDB-LOADER( 134): ACDB -> AUDIO_SET_AUDPROC_CAL
D/ACDB-LOADER( 134): ACDB -> send_audvoltable
D/ACDB-LOADER( 134): ACDB -> ACDB_CMD_GET_AUDPROC_GAIN_DEP_VOLTBL_STEP_COPP
D/ACDB-LOADER( 134): ACDB -> AUDIO_SET_AUDPROC_VOL_CAL
D/AudioPolicyManager( 134): setForceUse() usage 2, config 3, mPhoneState 2
D/AudioHardwareMSM8660( 134): addToTable stream 1
D/AudioHardwareMSM8660( 134): AudioStreamOutMSM72xx::standby()
D/AudioHardwareMSM8660( 134): Deroute pcm stream
D/AudioHardwareMSM8660( 134): deleteFromTable stream 1

Anyone know why this is appear? Shouldn't we be on MSM8660?

E/AudioHardwareMSM8660( 134): AudioStreamOutMSM72xx: channels
E/AudioHardwareMSM8660( 134): AudioStreamOutMSM72xx : sampleRate

I'm beginning to think this isn't fixable.
[HTC Rezound] dlumberg:
I remember seeing that at some point when I was still on CM9, I figured it was that msm8660 was wrapping the audio from msm72XX but I think it's probably some chunk of code that didn't get updated for CM9 because most boards don't use it.... I haven't seen that in CM10.

I was playing around with replacing the libacdbloader.so from evita and I was getting an error that ACDB wasn't properly initialized and the audio still was just fuzz and then cut out.

I noticed that the Sense ROMs and RUUs don't use libacdbloader, I'm wondering if maybe This Commit would work for us on Vigor. I may try this tonight.
[HTC Rezound] Snuzzo:
Trying it out on an AOKP build. Unfortunately it may not finish before I have to go AFK.

EDIT:

Ok you will also need Bruce's qcom audio tree as well.

EDIT2:

Building is broke with it. I give up on it, someone else will have to work on it as I don't have the time.
[HTC Rezound] kkozma:
Can you post the build error? If it's the same one as I was having when I initially tried Bruce's qcom audio, I know how to correct it.

If no one else gets to it, I can try again tomorrow.
[HTC Rezound] Snuzzo:
Same.

Sent from my ADR6425LVW using Xparent Red Tapatalk 2
[HTC Rezound] kkozma:
Ok, I've got a build running now. I'll report back when it's finished. Too say I'm not very optimistic would be an understatement.

---------- Post added at 09:46 AM ---------- Previous post was at 09:13 AM ----------

Well, it looks like I've managed to delete my recovery and fastboot isn't working, just says <waiting for device>... Any advice?
[HTC Rezound] shrike1978:
Can you put your SD card in a PC reader? If so, you can get a recovery PH98IMG.zip on it and get your recovery back that way.
[HTC Rezound] kkozma:
Yes, I can try that. Just super paranoid. But what's most irritating is fastboot not working, I'm running the jupunutbear hboot, this crap should work. GRRR
[HTC Rezound] kkozma:
Shocker socker. It didn't work. BT won't even turn on. I tried a make clean and now it won't build. Interesting.

make: *** No rule to make target `/home/vwmofo/android/cm10/out/target/product/vigor/obj/lib/libaudioalsa.so', needed by `/home/vwmofo/android/cm10/out/target/product/vigor/obj/SHARED_LIBRARIES/audio.primary.msm8660_intermediates/LINKED/audio.primary.msm8660.so'. Stop.

Ideas on this one?

I *REALLY* hate this phone... Regret the day it went on sale for $50 and me being a cheapass.
[HTC Rezound] Neo:
Could always go back to sense, strip the heck out of it, mod it put for speed and Bluetooth will work for you? Worst case scenario... What's the fun in that though right?
[HTC Rezound] Snuzzo:
Add that line back to your vendor blob and see what the result is.