I am having issues with A2DP streaming to my car kit since FRF50 with minor improvement now that I have installed FRF72 (BT headphones still work OK, though). Since it was OK in 2.1, I believe there might be an issue with A2DP paramenters - sampling rate, bit depth and the likes. I'd like to try and modify these but I don't have a clue how to even start.
If anyone can help.. thanks..
Nir
I believe those are hard-coded in the build, being values that are programmed into the BT chip, and changing them would require recompiling the source, which is currently non-available for Froyo. Your best bet would be to address Google with that issue, I guess...
Sorry, can't help more than that...
Related
Take a look at the \Windows\Init_Rom_V316.bts file. It clearly states in the changelog comments:
- Decreased output power by 2db for added RF robustness for compliance with the 4db output limit throughout all conditions.
This cuts the output of the Bluetooth Radio by 2/3's, roughly!
This is called every time Bluetooth is turned on. Under: HKLM\software\widcomm\BRConfig\General\RadioPostLoadScript
Anyone have an older version of this .bts file that has the higher output? Of any of you reverse engineers able increase the Bluetooth radio power?
PS. For those of you using the 3900 Bluetooth patch, take a look at the RadioWLANCoexEnable/Disable keys in HKLM\software\widcomm\BRConfig\General They are calling a .bts script that I have never had on my machine, I removed the path to the .bts script and the Bluetooth Radio Memory load errors decreased dramatically, as did the time it takes to turn the Bluetooth off and on. The keys are blank by default and only populated when you install the 3900 patch, apparently the patch is missing some files.
Hope someone finds this info useful.
Hope we can find that
it is a good analysis step frpm you if you we find this file it will be greate.
What will happen
what will happen if we removed this entry from or make it blank.
HI,
i have the file called in the registry on my machine. Perhaps it helps to analyze. There are two files existing. One enables and one disbles a function it seems.
It seems that the attachment upload did not work
BroadCom BlueTooth Stack 1.6
Do anybody use Broadcom Bluetooth Stack 1.6 it has a very obvious performance change but when i use this bluetooth stack i hear a continuous beeb every 3 sec. and also it has the same registry entries as 1.0.3900
Re: BroadCom BlueTooth Stack 1.6
here i've attached all BTS files for BRF6100 chip I've found in ROMs of different devices. I've compressed them because forum does not allow BTS attachments.
Init_Rom_V316.bts - original file from 1.40 ROM. "Version : P4.12"
Init_Rom_V316_from_old_rom.bts - from one of the first PDA2K ROMs, "Version : P2.12"
BT_Init_with_Coex_v1.0.bts - HP h6300 ROM, "Version : P4.12"
BT_Init_without_Coex_v1.0.bts - HP h6300 ROM, "Version : P4.12"
TIInit_2.3.16.bts - MPX300 ROM, "Major Version : P4.13c"
all of these files except for TIInit_2.3.16.bts contain "Decreased output power" string. Someone can try all these files to check the best BT quality.
To use it - rename file to Init_Rom_V316.bts and copy to "\Windows" dir.
But I think the scritps from other devices would not work on ours.
Re: BroadCom BlueTooth Stack 1.6
here is one more file
With this file ActiveSync connects a bit quicker than with default file. I don't have BT headset here to check sound quality.
Re: BroadCom BlueTooth Stack 1.6
mamaich said:
here is one more file
With this file ActiveSync connects a bit quicker than with default file. I don't have BT headset here to check sound quality.
Click to expand...
Click to collapse
I try this file... Makes no different in BT Headset. Range and sound quaility is about the same.
Wow, I don't want to get too excited, but I think we may have a winner.
I used the TIInit_2.3.16.bts file in place of the Init_Rom_V316.bts from my 1.40.00 System, and I have noticed a large decrease in static. It is still there, mostly in the background, very low. Range seems much better too. I'll have to do more testing, but my initial tests were done in a location where I usually have a TON of static. I also held the phone the opposite side of my head, and still not much static. If my testing reveals better overall performance, I'll kit this up into a CAB.
Excellent work everyone!!!
-Chris
DAMN DAMN DAMN DAMN!!!
Ok, second round of testing is a complete failure. While the initial testing that BTS file looked great, everything fell apart in an actualy call. The sound quality is totally inaudiable...
I feel that we are so close....
-Chris
Do these stacks have the A2DP profile? I can't seem to get A2DP and Headset working nicely together.
wamatt said:
Do these stacks have the A2DP profile? I can't seem to get A2DP and Headset working nicely together.
Click to expand...
Click to collapse
Maybe it depends on your headset. I just got the Zonet ZUB8100 and I can connect to it using Hands-Free & A2DP profiles simultaneously. It works pretty well in A2DP mode for listening to MP3s, not so well as a phone headset. Haven't tried using it to answer a phone call while listening to a MP3 -- I'll probably try that over the weekend.
I'm running a SX66 with radio ROM 1.12, BT stack 3900, but not with the BTS fix mentioned upthread.
i found the answer
sell the xda2s and buy a palm treo 650 - what a great device, should have done it months ago
it is so reliable and crash free
Any chance of one of the Devs having time to look into why the microphone input is not recognised or enabled on bt headsets in CM7?
Great progress has been made getting BT enabled, but I'd love to be able to Skype or record audio via BT...
Ill put a +1 on interest in this; but i know realistically, there are more critical things being fixed right now, so i am ok waiting..
I'm sure down the road, more devices will work, but I'm interested in the range issue. Is it a hardware issue (antenna) or is it a software?
sark666 said:
I'm sure down the road, more devices will work, but I'm interested in the range issue. Is it a hardware issue (antenna) or is it a software?
Click to expand...
Click to collapse
software. the wifi shares the antenna with the BT.
I'm sure it's just a matter of time before the bluetooth is able to handle a microphone. That's what I'm waiting for. I am loving the latest CM7 stable 4-11-11.
That's the only thing my nook is missing.... mic. I've been through all the ROMS and nothing beats the CM7 ...IMO. I will be more than happy to test any kernels for bluetooth stacks that the developers may come up with. I'm not familiar with what all they have to overcome to make it work but I am rooting for them. All the hard work that has already gone into this is AMAZING!!!!!!!
"We need more Cowbell"
I would like to know what would need to be done to replace the stock (closed source) Samsung bluetooth stack with an AOSP one.
The purpose would be increasing the bitpool, thereby increasing the quality of the bluetooth stereo audio in A2DP.
Note: some folks might not notice it a lot, and I can tell why. Certain types of music that I've listened to (eg house, dubstep, drumnBass, ambient) etc don't really suffer too much from the distortion.
However, the cymbals in jazz songs, as well as metal, due to the wide frequency response range required, suffer quite a bit- really anything around the 3kHz range
Could someone please let me know what needs to be done? I would even try to get the ball rolling myself if I could be pointed in the right direction
bump. Could someone at least mention a dev who has worked with replacing proprietary bluetooth stacks before to guide me as to how difficult this might be?
Otherwise, could someone guide me to a rom which uses an AOSP BT stack (such as a rom which is entirely AOSP) or a hybrid rom with an AOSP or BlueZ bt stack?
I've recently acquired a new car which has a built in stereo system (Renault Megane Estate 2012 Bose edition) which is able to receive CBR encoded A2DP streams. It works well, connects, music plays, even controls work.
Awesome!
Using catlog I can see that the bitpool that is negotiated is 51. While the sound isn't horrible, I believe the handsets (Samsung Galaxy SIII Int. and Nexus 7, both running CM10 nightly) are able to encode and transmit at a higher bitrate/bitpool then currently is set.
I've tried my best effort in changing this settings. I've built my own Ubuntu kitchen, followed all the guides and have from the looks of it compiled a successful ROM image. Sadly enough when I flash it, my tablet dies (black screen) and even CWM is destroyed. Using fastbood and USB I've been able to recover the tablet, so no problem there, but still, no working ROM. Even without changing something. But that is not what this thread is for, I'll figure that out eventually.
I am trying to recreate the results that are in the following topic : http://forum.xda-developers.com/showthread.php?t=1880298
Sadly, the files provided are not compatible with my CM10 devices and changing the source and then compiling it and replacing the files yields no result. Whatever I try, it stays at 51 (The bitpool it SENDS to the radio as max). There are several files which are connected to the settings, such as cbr.c , audio.a2dp.default.so, etc. but I don't really know what to change to get the desired results.
If anyone is able to help, that would be greatly appreciated. Point me to the right file where I can find the values to change, either in a compiled ROM or in the source so that I can compile it and change the files in
my running ROM using rootexplorer. Whatever works.
I would like to try settings as high as 125. But ideally, I would like to experiment what my headunit accepts, what it can be forced to, and thus finding the highest quality possible using my combination of equipment.
In this the Nexus 7 is the most important because that will be permanently located in the car.
update--
I have found a thread on bluez surrounding this topic.
http://www.spinics.net/lists/linux-bluetooth/msg23091.html
Could someone more knowledgeable then me please take a look at this for me and maybe change the file? Sadly that goes way beyond my programming knowledge, but I would really love to give it a try!
update--
Some extra information and a good explanation as to why I am looking for this (and maybe more people with me).
Bitpool values as high as 128 are possible on Windows Mobile devices (including mine), which means they are possible in A2DP. Such a high value is necessary for some genres of current music, which are highly
compressed (the problem was once discussed in one of Xiph Foundation's articles). SBC is unable to encode such material properly if it doesn't have enough bandwidth.
Click to expand...
Click to collapse
I've done some more tests editing and replacing files and I think I've actually gotten it to sync higher but it still displays it's at 51. The sound just sounds a lot better, but of course, that can always be a placebo effect. :silly:
So, anyone have any insight, or who can point me into the right direction of what needs to be changed and where? As said, I think I have reached the quality increase (bitpool 100) but the logs still display 51.... not quite there yet. And in light of people using the Nexus 7 in a cars a lot (which I also intend) and the borked headphones output I read everywhere, CD quality streaming over A2DP (It's possible) would be awesome!
Kitchen fixed
So I got my kitchen working and am cooking working ROM's.
Just getting the right files changed is giving me some problems.
I think I fixed most of it, but for some reason when I check the logs it still states that it's sending a max bitpool of 51. I believe in the background it's using the 128 as I stated in the source files, but still. I would like the logs to show the same, just to acknowledge I'm a not having a placebo effect.
The files I have changed are the following:
/android/system/external/bluetooth/bluez
a2dp.c
gsta2dpsink.c
gstscenc.c
liba2dp.c
pcm_bluetooth.c
I used the patch listed above on the pcm_bluetooth.c. And I do believe it overrides the settings and it's not set to 51 anymore but the 128 I put in all the files manually. Music sounds great, but it's hard to subjectively test.
Hopefully we can find some people who have a greater understanding of bluez.
Little kick
Little kick to see if someone wants to assist me on this or not. I think it could potentially benefit a lot of people making Bluetooth audio/A2DP go from barely adequate to High Fidelity!
I'd love to help you test this - I also find the A2DP quality to be lacking in a lot of more "active" or compressed music. Acoustic and softer music sounds great, but rock/metal tends to sound like a 128kbps mp3. It actually seems to sound better from my Galaxy Nexus than the 7 as well. I'm running a Bugless Beast ROM now but was running CM10.
Also, not sure if you've seen this but I found an article (soundexpert.org/news/-/blogs/bluetooth-audio-quality-a2dp, sorry can't post links yet) that shows the bitrate per bitpool value. At a bitpool value of 53, the bitrate is around 320kbps. A2DP itself supports a bitrate of up to 512kbps for stereo, but through other optionally-supported codecs. SBC however, in this profile, only seems to go to ~320. It might be worth checking out if your car stereo supports mp3 over A2DP - there is an option in /etc/bluetooth/audio.conf to set MPEG12Sources from 0 to 1 and SBCSources from 1 to 0.
ROM up for download
Hi there, thnx's for joining the cause.
I compiled a new daily today with settings set to bitpool 128. But I don't really hear much change, maybe the setting is too high, maybe something else is going wrong. As stated above, in the logs I can only see it sending 51 as max pool to the device and setteling with it. But since I'm using an edit pcm_bluetooth.c it should override that setting, say it's going to do 51 and then stream and the values I defined in the files.
.....in theory at least...... the only subjective evidence I have for this are my own ears.
So, I will provide you with access to the 128 version and am going to compile a 64 version while I'm at it.
Use an FTP client to connect to:
host: oss.quindorian.org
user: XDA
pass: ROMROM
Anyone is welcome to give it a try. I have put limits on the FTP site, so please beware of that. But I'll put ROM's there you can try and report back on. Tell me if you think it does nothing or if you think it makes it sound like a singing angel. Any feedback is appreciated.
As source I use the CM10 repository so I am basically building modded nightly builds. Today it allready has the 4.1.2 flavor with the newest drivers and everything included. Don't forget to flash gapps if you need them.
Understand
ChrisK15 said:
Also, not sure if you've seen this but I found an article (soundexpert.org/news/-/blogs/bluetooth-audio-quality-a2dp, sorry can't post links yet) that shows the bitrate per bitpool value. At a bitpool value of 53, the bitrate is around 320kbps. A2DP itself supports a bitrate of up to 512kbps for stereo, but through other optionally-supported codecs. SBC however, in this profile, only seems to go to ~320. It might be worth checking out if your car stereo supports mp3 over A2DP - there is an option in /etc/bluetooth/audio.conf to set MPEG12Sources from 0 to 1 and SBCSources from 1 to 0.
Click to expand...
Click to collapse
Yeah, I understand what that article says. But for me, the quality just isn't up to par to listening to a 320Kbit stream. Also, there is what A2DP officialy supports and there is what works. I'm shooting for the last type. If I can get a 1000Kbit stream between my device and my headunit, I will, even if it doens't add much above say 786Kbit, more is always better in this case. If it works that is, ofcourse.
Because I wish to use spotify, I believe my only choice is to use the SBC encoder. Spotify will never let you transfer it's source file to anywhere because of DRM. Alternativly, if we could enable an AAC stream or something (also supported I believe) we'd need less bitrate/bitpool for better quality! And from what I have read, the SBC encoder standard used it just quite crappy. So while a 320Kbit LAME encoded MP3 might sound great/perfect, using a sub-standard encoder can still give it artifacts and low quality. Thus the hunt for insane amounts of bitrate!
Awesome, I'll definitely give it a shot. If it's possible to exceed the Bluetooth standard spec then that'd be awesome. I'm more worried about our receivers not being able to support the higher bandwidth - my head unit is new but only supports SBC unfortunately.
Cool
ChrisK15 said:
Awesome, I'll definitely give it a shot. If it's possible to exceed the Bluetooth standard spec then that'd be awesome. I'm more worried about our receivers not being able to support the higher bandwidth - my head unit is new but only supports SBC unfortunately.
Click to expand...
Click to collapse
Cool, I just put the bitpool64 version there too. Tested it and I notice no real difference. Sadly the quality is still not great, it's not horrible.... but certainly not great so I still feel like my settings are maybe not having any effect whatsoever. As reflected by the logs using catlog. It sen bitpool 51 max and settles for that. For all the values I have changed in the files and that stay the same, I really do not understand. Wish I could fix that, but with my knowledge I have just run out of places where to look.
Let me know if in your case it makes any difference!
I just tried it out and to me it seems like there's an improvement. I normally stream Pandora One in my car, and that definitely seemed like it had more clarity. However Google Music streaming sounded the same, although it was already good to begin with. I would think that compressing more highly-compressed music from the start (Pandora) would have a worse effect on quality than less-compressed music, which seems to be the case. Or maybe I'm just hearing things
Thanks for looking into this, I've been trying to find a way to do this for a while!
Quindor said:
Hi there, thnx's for joining the cause.
I compiled a new daily today with settings set to bitpool 128. But I don't really hear much change, maybe the setting is too high, maybe something else is going wrong. As stated above, in the logs I can only see it sending 51 as max pool to the device and setteling with it. But since I'm using an edit pcm_bluetooth.c it should override that setting, say it's going to do 51 and then stream and the values I defined in the files.
.....in theory at least...... the only subjective evidence I have for this are my own ears.
(...) .
Click to expand...
Click to collapse
perhaps you can test if the patch does anything - by setting bitpool to some very LOW value ?
ChrisK15 said:
It might be worth checking out if your car stereo supports mp3 over A2DP - there is an option in /etc/bluetooth/audio.conf to set MPEG12Sources from 0 to 1 and SBCSources from 1 to 0.
Click to expand...
Click to collapse
On my CM12.1 official nightly ROM (2015/12/03) for my Samsung i9505, there is no file audio.conf
Does that mean I can simply create it with the two lines
MPEG12Sources=1
SBCSources=0
in order to test wether a bluetooth SNK device such as a car stereo or a headset supports mp3 over A2DP?
So does anyone have some actual logs or HCI captures showing bitpool above 53?
..
When calling using the default dialer app, the Bluetooth Car audio behaves abnormal.
It screeches, pings and pops. I saw a fix for CM7 and it was supposedly merged into CM10, do any of you guys have a similar problem and hopefully a fix.
EDIT Bluetooth audio works on newer Bluetooth head-units and my laptop. not in my stock 2008 Nissan (Bose Nav Unit)
Any thoughts?
Thanks
jumpmanvi said:
When calling using the default dialer app, the Bluetooth Car audio behaves abnormal.
It screeches, pings and pops. I saw a fix for CM7 and it was supposedly merged into CM10, do any of you guys have a similar problem and hopefully a fix.
EDIT Bluetooth audio works on newer Bluetooth head-units and my laptop. not in my stock 2008 Nissan (Bose Nav Unit)
Any thoughts?
Thanks
Click to expand...
Click to collapse
2008 system will be outdated and won't work at their best with the newer software unless there is some updates for them. That could be something to look for.
Also, if I'm not mistaken, the BT is cooked into the kernel (could be quite wrong here).. So trying a different one might help. Although, keep in mind that this is a shot in the dark.