Another Headset discussion with a twist... Bluetooth.

Though I have never used it, the company is known for well above average quality within a very cheap budget:

http://www.amazon.com/NuForce-BT-86...e-Grade/dp/tech-data/B005CYOOK6/ref=de_a_smtd
It says there is a built in mic, though I dont see where it would be from the pictures. Still, for under $100 it is probably your best bet. Looks a bit uncomfortable though.

Another good choice might be these:
http://www.amazon.com/Sony-DRBT50-S...092&sr=1-10&keywords=Stereo+Bluetooth+Headset
Although I hate pretty much every Sony product these days, the limited availability of bluetooth heaqdsets around the $100
range means these might actually be some of the best you will find. My major concern is this:
Frequency Response: 100 - 4,000Hz

That number is absolutely terrible. But what I am wondering is if the bluetooth spec can even transmit above the 4kHz frequency? I dont use BT that often, but when I did voices always sound muddy from lack of high frequency response. It could just be a limitation of the spec which is why you dont see BT used much for actual audio.

EDIT: I dont know if it is a real limitation or not, but the NuForce specs say this:
Frequency Response: 20Hz to 22kHz


and another possible choice:
http://www.amazon.com/Creative-WP-450-Bluetooth-Headphone-Invisible/dp/B005XPFYBM/ref=pd_sim_cps_4



If you plan to pair this headset to your phone, I hope your phone supports high-bitrate bluetooth. If not, it is possible that a custom kernel for your phone would add support. The best audio quality over bluetooth that I know of is on the EVO 3D, a really great dev who is now on the DL makes a very nice kernel with greatly enhanced audio quality and high bitrate streaming over BT. The HTC One line would also be a good choice if you have one. Also a custom ROM is a good choice for an Android phone because of DSP manager where you can set an EQ and the compression amount used over the BT connection:

 

apt-X codec would probably be the best for audio, but you are right it is not supported by the Gnex. To add support for that I think would be more in the kernel than the ROM for initial compatibility. It is weird to me that the Galaxy Nexus doesnt support the codec, because the earlier Galaxy Tab and the Note from Samsung support the codec. My guess is that Google did not specifically want it in the Nexus, and since the phone is Google's baby and follows a specific rigid set of features to be known as "stock Android", this new codec is not yet supported. Ill ask Ezekeel about the possibility of getting this support for the phone though, he and Faux are the only two people who are even remotely likely to be able to do it. Too bad Chad doesnt have the phone, it would be child's play for him.

Good news though is that since you own a Nexus, the entire point is the custom ROM's, and Cyanogen are the people behind DSP Manager. So guaranteed you can tweak that to help things a bit. Whether CM10 has the APK included already I dont know since I am no longer a fan of Cyanogen Mod, but it should be there.


The only custom kernel that I know of for your phone that says it has the latest updates to the TWL6040 chip that your audio is processed through is Faux123's kernel. Most of the rest say nothing about pulling patches for audio and some specifically say that the Texas Instruments patches and commits were removed. I dont know if it will help or not, since the bluetooth specifically goes through a 96kHz output anyway and does not have a low power option, but most custom kernels support changing the audio to high performance mode.
Sonicxml (popcorn kernel) might also have these patches and optimizations. He pulls pretty much everything that is pushed to the OMAP4 repository.



Technical stuff no one cares about:
The hardware design of your audio chips appears to me as if it mixes in 48kHz sample rate, goes through a gain stage, then the DL2 equalizer, and then get up sampled to 96kHz sample rate where the audio then exists the OMAP4 and goes into the TWL6040 codec chip. The DAC it runs through is only a 96dB (pretty shitty), followed by a volume control that adjusts in 2dB steps (this is the part of the chip that specifically controls the volume of the bluetooth), then hits a +4.4dB gain operational amplifier before finally exiting the TWL6040 chip and going to whatever bluetooth chip is used. So even though it is advertised that the Bluetooth is 96k, deep down it is really only standard 48kHz.

 

Thanks for the kind words everyone




Pretty much all custom kernels give the option to select high performance audio, it is as simple and flipping a bit flag in some code that is already there. The chipset in the Galaxy Nexus has a special part for acceleration of audio and designed to be low power, this part uses 88.4kHz sample rate. The high performance setting uses 96kHz sample rate, and may bypass other parts of the HA chip as well. Really you want the highest sample rate possible for audio, but if the source audio is a low sample rate then it doesnt matter to have anything higher. And since it is a cheap little phone speaker it wouldnt matter much because of that either, so really there is no point to activating the high performance audio and stepping down to 88.4kHz sampling rate is nothing major anyway so you shouldnt be able to even tell the difference.

Also the high performance audio setting has nothing to do with Bluetooth, only the headphone output from the phone. Bluetooth is locked to 96kHz sample rate, however as I said before deep down in the chipset you can find that it is really only an up-sampled 48kHz rate. The only way to change this would require some MAJOR code changes within a kernel to intercept the audio path and bypass much of the hardware accelerated audio decoding and instead do the processing within the CPU using software. If done right, this would provide a vastly superior sound (hard to believe I know). The problem is that I know of only 1 person who would ever want to even attempt that much work, and he went the GS3 route instead of the GNex.


One thing it looks like you are not aware of is that although all kernels are based on AOSP code and the ROMs are based on AOSP code, they are not all fully compatible with each other. The CM team did some stupid shit and now their codebase is not compatible with AOSP code or kernels. As such if you run into problems with wifi, deep sleep, or other random features it is because Franco's kernel is not Cyanogen Mod compatible. If you run a CM based ROM you really should run a CM friendly kernel as well, which is why I suggested Faux's. The issue is that the Cyanogen team decided to be egotistical assholes and steal some work to pass off as their own, and to try and alienate a few specific developers they implemented changed to their codebase that forces most mods people have done in the past and the standard for how things are done to no longer work on CM based ROMs. You now have to implement certain features how the CyanogenMod team decides they want to you implement things. It really split the development community in half, with some refusing to redo all their work to support a few assholes, and some willing to go along because they feel that CyanogenMod has a bigger following of people. Ill break down a list of some popular ROM's and kernels:

ROMs:

Cyanogen Mod based:
Eclipse
CM7, 8, 9, 10
Paranoid Android
ViciousCM
AOKP
JellyBro


AOSP based:
VanirAOSP
LiquidSmooth
XenonHD
SlimBean
BAMF Paradigm
JBSourcery
Redemption
ViciousJB
Team EOS 3
Jelly Belly



Kernels:

CM friendly:
Trinity
Faux123
Leankernel

AOSP friendly:
Glados
Popcorn
Peanutbutta Jelly
Franco


I highly suggest you give Faux and Popcorn a try at some point.



Cyanogen Mod has really been great for the development community, and has some real amazing talent in it. Android modding would be no where close to where it is today if it wasnt for the CM team. However, as of late the work coming from CM has been pretty bad, and the attitude's of the team members even worse. The biggest issue is with Toastcfh. Who has done some amazing things in the past, but messed up really bad about 6 months ago. And to keep his reputation, lied about what he did to everyone and continues to falsify blame on others to prevent people from seeing his guilt in the matter. For the stealing of other's coding and work, and abuse of admin powers to cover up said actions he really should be removed from the CM team and banned from all major Android development sites.

Thats not to say you should never ever use a Cyanogen Mod based ROM, you can if you want and there is some good stuff out there. I just personally dont like to use Cyanogen Mod any longer, partly because of their lack of extra features too. I can find something exactly like I am looking for from the main AOSP tree so I just stick with that. I did have fun playing with Paranoid though. Liquidsmooth was my favorite team back in Ice Cream Sandwich, now I am still deciding on which I am liking best for Jelly Bean.

 

Ezekeel is currently looking into getting APT-X bluetooth codec fully supported within his kernel. He is one of two dev's who would be able to do it if the feature is at all possible to add in. If he says no, then I think you are SOL for that feature.