yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] dandreye:
While automating that for arbitrary ROMs is a real challenge (someone actually tried creating a signature-based patcher but IIRC it was never released) I'm more than happy to share the changes that went into file /system/lib/hw/bluetooth.default.so of my Android 7 Nougat stock ROM XEU-A310FXXU4CRG2 just to illustrate the method, which is wholly based on the one documented by ValdikSS for Android 5-7:

1a) Setting 4 subbands when A2DP source (UE) connects to sink (DAC)
@0019DC26(-7000=00196C26) where bta_av_co_sbc_caps and/or btif_av_sbc_default_config resides:
20011004013502 -> 20011008013502

1b) Setting 4 subbands when A2DP sink (DAC) connects to source (UE)
@0019DC1F(-7000=00196C1F) where bta_av_co_sbc_sink_caps resides:
200FF00C033502 -> 200FF008033502

2) Lifting 328Kbps max bitrate cap for EDR:
At 0019C456(-7000=00195456):
48014801 -> 7A027A02 (634Kbps, which comes from ValdikSS's Bluetooth A2DP SBC Bitrate Calculator)

3) Masking 8 subbands when talking to the sink, thereby enforcing 4:

Subbands in A2D_BldSbcInfo in a2d_sbc.c:
*p_result++ = p_ie->block_len | p_ie->num_subbands | p_ie->alloc_mthd;
https://android.googlesource.com/platform/system/bt/+/refs/tags/android-7.0.0_r36/stack/a2dp/a2d_sbc.c#81

.text:000C3A6C LDRB.W R12, [R1,#2] << Load p_ie->block_len
.text:000C3A70 LDRB R4, [R1,#3] << Load p_ie->num_subbands
.text:000C3A72 LDRB R0, [R1,#4] << Load p_ie->alloc_mthd
.text:000C3A74 ORR.W R4, R4, R12 << Combine them
.text:000C3A78 ORR.W R0, R0, R4 << Combine them
.text:000C3A7C STRB R0, [R2,#4] << Save in p_result->Blocks / Subbands / Alloc

Hence @C3A70(-7000=BCA70): CC78 -> 0824 for:
.text:000C3A70 MOVS R4, #0x8 << Use this: #define A2D_SBC_IE_SUBBAND_4 0x08 /* b3: 4 */

Subbands in A2D_ParsSbcInfo in a2d_sbc:
p_ie->num_subbands = *p_info & A2D_SBC_IE_SUBBAND_MSK;
https://android.googlesource.com/platform/system/bt/+/refs/tags/android-7.0.0_r36/stack/a2dp/a2d_sbc.c#128

.text:000C3ABE LDRB R3, [R1,#4] << Load Blocks / Subbands / Alloc again
.text:000C3AC0 AND.W R3, R3, #0xC << #define A2D_SBC_IE_SUBBAND_MSK 0x0C /* b3-b2 number of subbands */
.text:000C3AC4 STRB R3, [R4,#3] << Save in p_ie->num_subbands

Hence @C3AC0(-7000=BCAC0): 03F00C03 -> 03F00803 for:
.text:000C3AC0 AND.W R3, R3, #0x8 << Use this: #define A2D_SBC_IE_SUBBAND_4 0x08 /* b3: 4 */

I do realize masking 8 subbands like that is a rather brutal hack but it works for my applications, so I don't mind.

Btw do you happen to know how to pull BT logs (pcap traces) with Samsung SM-A320FL running stock Android 8 Oreo ROM, at least a rooted one? Unlike SM-A310F that has plain BT HCI snoop log feature working, SM-A320FL won't include AVDTP traffic even into a full bug report (with BT HCI snoop log enabled of course), so I'm having to connect to an Ubuntu18-based A2DP sink running Wireshark every time when testing yet another mod on it.
[Android Software/Hacking General [Developers Only]] dandreye:
Yep and I was prepared for it knowing that I'm going quite above 596-618Kbps that XQ/DC was tested up to (mostly successfully).

Will keep you updated although time is a real bottleneck as usual, causing delays.

That one's actually quite easy to try: I already had to reduce it from default 53 down to 51 in my SM-A320FL where I couldn't find a way to raise AVDTP MTU and so it kept stuffing frames into default 663-byte SBC payload, hence 2 frames per packet instead of 3 causing audio clipping. I now feel this might have been the reason for several other reports about audio issues at high bitrates as ValdikSS's Bluetooth A2DP Codec Dissection tool doesn't display the # of frames per packet in the actual stream in pcap. It'd be nice to see it and some other framing data on the actual stream from Bluetooth A2DP SBC Codec Bitrate Calculator added into it one day.
[Android Software/Hacking General [Developers Only]] klaberte:
Exposing my ignorance yet again, my understanding was that ValdikSS was showing precisely how to alter the source code of a ROM, which only works if you know how to compile your own ROM after the source is updated, right? (I have never bothered to learn) However, what you showed looked more like editing binaries/executables, which I haven't the slightest notion how one would start. Are you using some type of un-compiler to show what source code controls the specific values for that part of the executable?
[Android Software/Hacking General [Developers Only]] dandreye:
You're right. In fact he shared the following methods in the 2nd post:

- Recompiling the source code with his changes integrated manually into it (before they were accepted/merged, e.g. into LOS)

- Binary patching /system/lib/hw/bluetooth.default.so in Android 5-7 ROMs (incl stock ones) with Bluedroid BT stack

Like you I can't be bothered mastering ROM compilation from scratch and will hardly ever get Samsung BT source code anyway (could only find their kernel source code so far, which doesn't seem to contain BT code), so due to certain knowledge of Assembler I used the latter method. In fact in theory it can be applied (customized of course) to any ROM no matter what anyone claims. The key here is to understand the logic in the disassembled binary code (a tool like IDA Pro can be used to disassemble it), which is best done when you have a matching source code at hand. Well, at least roughly matching, so that it can be used as a reference/guide as it seems to be pretty similar for any common Android version with minor changes: e.g. some idiots at Samsung decided to drop part of the AOSP logging essential for our exercise, apparently deeming it no longer necessary. Perhaps some really bright minds could even do it w/o the source code... it's just a matter of time after all.
[Android Software/Hacking General [Developers Only]] klaberte:
I am less optimistic a good solution is coming for anyone but android developers. I have been crossing my fingers for about 18 months, with very little evidence that things are even moving forward. I could try various LineageOS ROMs, searching for one that at least had ValdikSS patches...
[Android Software/Hacking General [Developers Only]] klaberte:
I know that, for some models, Samsung devices do not make grabbing the btsnoop_hci.log very easy. You can look at this post and see if any of these suggestions work for you.

How do I determine which A2DP codecs my phone supports/is currently using?

Bluetooth's Audio Profile A2DP supports multiple codecs. All devices have to support SBC (subband codec), then they can support additional "optional codecs" like MP3 and AAC, or "non-A2DP" codecs ...

android.stackexchange.com
[Android Software/Hacking General [Developers Only]] dandreye:
Thank you,

Writing btsnoop_hci.log directly into a file doesn't work on the Android 8 one for sure, and when I take a (full) bugreport as explained here there's no AVDTP/A2DP at all in the resulting trace for some reason, and the trace itself is much smaller than btsnoop_hci.log would be with the Android 7 one for the same audio duration, so I doubt it's some human error while I'm extracting the trace from the bugreport with that btsnooz.py tool. Please find one of such traces attached.
[Android Software/Hacking General [Developers Only]] zyhk:
Did you look at a folder "/data/misc/bluetooth/logs"? This folder is the usual place where new Androids log bluetooth HCI events.

By the way, MTUs for EDR-2Mbps and EDR-3Mbps are 672 bytes and 1008 bytes respectively. TWS earphones usually use EDR-2Mbps and others use EDR-3Mbps.
[Android Software/Hacking General [Developers Only]] dandreye:
I just have: it's empty (I enabled BT HCI logs in Developer options, connected to the sink, sent some audio, disconnected from the sink and disabled BT HCI logs). It's a rooted SM-A320FL one.

Do you happen to know if function a2dp_sbc_encoder_update in a2dp_sbc_encoder.cc is the only place where MTU is enforced in Android 8 AOSP? My attempts to raise it there don't seem to make any difference and I can't find where else it's enforced besides that one. I already checked a similar function in LOS15.1 with ValdikSS's diffs and can't find any other MTU enforcements there either:

https://review.lineageos.org/c/LineageOS/android_system_bt/+/228548/3/stack/a2dp/a2dp_sbc_encoder.cc#b1
[Android Software/Hacking General [Developers Only]] zyhk:
I think you cannot enforce the MTU size. It is determined by receiver devices. Try to use non-TWS earphones or headphones. Or aptX capable TWS earphones (QCC 30XX SoC devices use EDR-3Mbps).
[Android Software/Hacking General [Developers Only]] dandreye:
Well I was also trying to find whereabouts it's negotiated or at least exchanged if at all and couldn't find anything like that (perhaps it is at some lower layers though?). Meanwhile if MTU is restricted in that SBC function then wondering what exactly elsewhere prevents restricting it to a desired (higher) value there. I'm interested in it with SBC in mind though: otherwise I could've used AptX-HD and LDAC.
[Android Software/Hacking General [Developers Only]] klaberte:
I don't know if this is any help, but IIRC, SBC-HBR, unlike other bitrate doubling methods, does not increase packet size. It just sends the same size packet at twice the packet rate.

You can see this by using ValdikSS' calculator and switching between 8 and 4 subbands.
[Android Software/Hacking General [Developers Only]] dandreye:
Yes although the frame size seems to be 4 bytes smaller (115 bytes with SBC-HBR JS-16-4 vs 119 bytes with normal JS-16-8), so I think those more frequent packets should be (4 times # of frames per packet) bytes smaller accordingly... unless yet another frame can fit into the packet as a result (MTU permitting). The logic seems to be putting as many frames into a packet as can fit with the applicable MTU as the traces suggest.
[Android Software/Hacking General [Developers Only]] Alecjasonn:
If I wanted to do this for the OnePlus 7 Pro, how would I patch the bluetooth stack? Or is that too difficult to explain? I really want this mod lol
[Android Software/Hacking General [Developers Only]] klaberte:
Easiest path for you would be to install LineageOS.

OnePlus 7 Pro (guacamole) - LineageOS ROMs

LineageOs ROM OnePlus 7 Pro (guacamole) Official roms Download last nightly build (2023-01-08) (mirror EU).LineageOS 20.0 [Recovery file (2023-01-08) (mirror EU)] Previous version (nightly) (2022-12-18) LineageOS 19.1 – [ Android 12.1 (Snow Cone) ] [Recovery file (2022-12-18)] Previous version...

lineageosroms.com
[Android Software/Hacking General [Developers Only]] Alecjasonn:
I honestly don't like roms that don't come with GAPPS. Does crdroid have it? I read that it does
[Android Software/Hacking General [Developers Only]] Preparedtobereckless:
Has this adjustment been figured out for android 11 or lineage 18? I ran this mod before on android 9 and it made A MASSIVE difference, i have a magisk module that lets you choose your bit rate up to 800kps and it made such a difference. I haven't figured out how to do it on android 11 yet, any input would be appreciated!

Edit: Read the previous pages about commits and "dual channel" but on my LG v20 LOS 18 rom when i select dual channel all i get is distorted audio
[Android Software/Hacking General [Developers Only]] blackhawk:
Stock Samsung's support the proprietary SSC which works very well, now, with the Buds.

Be interested to know how these new bt stacks compare to it.
[Android Software/Hacking General [Developers Only]] klaberte:
Really, just about any bluetooth codec with high enough bit rate will be great. When we talk about a codec being good or bad, we are usually characterizing how good it can sound with the lowest bandwidth. In other words, codecs are often judged not on how they sound, but on how much compression they can do before impacting sound quality.

This is even true for SBC, which is the universally required CODEC. It got a bad name because the original designers were worried about wireless interference (remember we are talking almost 20 years ago). It turns out they were too conservative to produce good sound, but "It just worked (TM)" and it was "Good enough (TM)".

The adjustments discussed in this thread simply have figured out how to increase the bitrate (bandwidth, i.e. how many bits/sec) on SBC. Too bad most people didn't realize how easily this could have been done. If they had, we'd all likely be using the same, open-source codec without all of these proliferations, incompatibilities, blah, blah...

All of the better sounding codecs available today also use higher bandwidths than the default SBC settings. That includes Samsung's scaleable codec (which, I agree, sounds very good on the samsung buds). LDAC uses between 2-3x as much bandwidth as the original SBC, no wonder it sounds good! I now have the same buds, but am using a Pixel phone. Still, it uses AAC, and sounds pretty good.
[Android Software/Hacking General [Developers Only]] klaberte:
Generally, it seems the best way to achieve this higher quality SBC *is* to use Lineage. My device (PIxel 5) just started to get official support of Lineage. You can see it in the Developers Settings, but seems that my current build has it turned off. Others using the Pixel 5 tell me that it worked on the earlier, more experimental nightly builds. I am optimistic it will come on soon for me, and may already be working for your phone. But, as the OP has said, there are more than a few devices where this should work, but for some reason, just doesn't. So we all just need to have some luck to get a working phone-headphone combination.
[Android Software/Hacking General [Developers Only]] blackhawk:
The Buds+ sound very good on SSC* with a dial in by the Poweramp equalizer. A lot better than the firmware sounded from even half a year ago.

AAC is noticably not up to SSC... I never use it.

I still wonder how the high bitrate SBC stacks up to SSC. While higher bitrate is needed to carry more information it doesn't necessarily mean optimum rendering.

As for LDAC I've never been able to sample it as none of my listening devices support it. It's max bitrate rate is slightly higher than SSC.

* my stock 10+ will default to SBC on utube junk, don't think I can't force it to SSC. It sounds pretty good though. I'll play with it bit more. I don't think any of my apps tell the actual bitrate output of any of the codecs. With SSC you can't force set maximum bitrate only as variable in Developer options.

I'm curious now...
[Android Software/Hacking General [Developers Only]] Preparedtobereckless:
Yea i have lineage 18 official on my LG V20. I have "dual stereo" which breaks TWS. I used to run SBC at 800KPS on android 8 and it sounded SICK. Trying to figure out how to do that on android 11 and have found articles but not really guides, so it seems possible but? @ValdikSS is the the OG on this topic but i read somewhere he didnt have a newer phone to test on. Id just love to get my boosted sbc running because all the Chinese super speakers run off sbc and I tested today and its greatly reducing the quality of the pair of w-king speakers i recently purchased. thanks everyone!
[Android Software/Hacking General [Developers Only]] klaberte:
What do you mean by dial in by the Poweramp equalizer? You just mean normal equalization to match your tastes, right? There is no dial in Poweramp that affects the Bluetooth codec parameters, right?
[Android Software/Hacking General [Developers Only]] blackhawk:
Exactly.

Poweramp does support 24+ bit throughput though. The bt stack is the weak link.
[Android Software/Hacking General [Developers Only]] klaberte:
Actually, it might not be. Or more precisely, the impact of encoding and decoding the audio via BT codecs may be very, very difficult to hear, especially once bitrates go above 400 bits/sec.

Here are some samples you can try. You may think you can hear a difference, but try a real A:B:X blind test, and you may be surprised. Or in my case, humiliated. I can show you how to do the blind test if you want.

Test Set 1: Classical Music, Full Orchestra and SATB Chorus, Loud Volume

OFortuna.zip

drive.google.com

Test Set 2: Classical Music, Female Soloist with Orchestra, Soft Volume

Intrutina.zip

drive.google.com

Test Set 3: Jazzy Pop, Female Soloist with Guitar, Piano, Bass, and Drums, Medium Volume

DontKnowWhy.zip

drive.google.com
[Android Software/Hacking General [Developers Only]] klaberte:
If you want to know more about these test files, please read the section "Audio Examples" near the end of this report:

http://bit.ly/SBC_explained
[Android Software/Hacking General [Developers Only]] blackhawk:
Everything I have are CDs and HDCDs that were ripped as .wav files thereby preserving their HDCD subtext. HDCDs have around 22+ bit resolution so they are my standard.

Damned if I'm upgrading -again- to 24 bit or higher. 6000+ songs are too many to upgrade.

Tired of that game.

Piano and harpsichord music are good for judging a recording, file type or codec🤣

I'll use mp4's if I can't get .wav files but never mp3's... at least until I can download in a better format.
[Android Software/Hacking General [Developers Only]] klaberte:
Then you should have no problem differentiating between 16 bit CD WAV files, and those encoded, and then decoded, using the SBC codec. All you need to do is present evidence here that you can correctly pass an ABX test.
[Android Software/Hacking General [Developers Only]] klaberte:
Here are some instructions:
[Android Software/Hacking General [Developers Only]] blackhawk:
I don't see the point; all bt codecs are inferior to direct 24 bit throughput.

bt is the weak link.

bt is convenient and can sound pretty good but that's about it. I'm stuck with what my stock N10+ can give anyway🤣

I had a Denon flagship reciever with 7 Technics THX mains* plus a dual 400 watt 12" subwoofer system.

Even the UHQ upscale output sounds like dog meat by comparison to the Denon.

So I'm not getting too worked up about all of this...

*bought 3 systems after they were discontinued for just the mains. Technics can make excellent sealed speaker systems... if they want too.

Didn't like the subwoofers or smaller rear speakers so just used the 2 (x3) front mains plus 1 of the center mains.
[Android Software/Hacking General [Developers Only]] klaberte:
The point is that I'm calling your bluff. I think you believe something that you cannot actually prove. I too think I have good gear and great ears, but I was humbled by this test.

Do the ABX test between these two files (from the OFortuna set above):

OFortuna_test.wav

OFortuna_test_jp_n4_l16_bp53.wav

The first was ripped from a CD. The second has been encoded and then decoded by the SBC codec at 634 Kbits/sec. Which is way, way more compressed than the original, encoded at 1,411 Kbits/sec (standard CD encoding). Use the very best equipment you can get your hands on.
[Android Software/Hacking General [Developers Only]] klaberte:
Please don't be angry, it is not personal at all. Just I am trying to make a point that higher bit SBC is surprisingly transparent.

Proof would look like this, which I just did with the smallest compression (146 kbits/sec), which is trivial to pass:

foo_abx 2.0.6d report

foobar2000 v1.6.5

2021-04-23 14:15:08

File A: OFortuna_test.wav

SHA1: 890e648f173ac57ace49df580f03c701de4efa03

File B: OFortuna_test_jp_n8_l16_bp20.wav

SHA1: 9ef388c5eed42dc2c00906e79b4ca769f0bacf48

Output:

Default : Primary Sound Driver

Crossfading: NO

14:15:08 : Test started.

14:15:24 : 01/01

14:15:31 : 02/02

14:15:36 : 03/03

14:15:46 : 04/04

14:15:54 : 05/05

14:15:59 : 06/06

14:16:08 : 07/07

14:16:14 : 08/08

14:16:14 : Test finished.

----------

Total: 8/8

p-value: 0.0039 (0.39%)

-- signature --

9e5898f864f4e089b57482fb32fe0126ad51b7a1
[Android Software/Hacking General [Developers Only]] blackhawk:
You loss the HDCD subtext the second you go to SBC. To maintain the subtext and resolution you need to stay in the digital realm until you go into a 24 bit DAC.

Even if your SBC encoder could process the subtext it grossly lacks the needed bandwidth to preserve the 22+ bit image.

To actually glean all the subtext you need the proprietary HDCD decoder; a 24 or 32 bit DAC will glean roughly 90-92% of the subtext.

Tony Hardin at Denon was kind enough to help me understand the HDCD system requirements and workarounds.

Mad? Just curious... as I can't alter my bt stack it's simply a curiosity to me for now.

If it was only possible it be nice to be able to force the maximum bitrate rate for all the codecs though😒

There are even more damning issues with bt if using with open air stereo driver systems. If the high frequency cutoff is set below 50khz and especially 22 khz you're losing a huge chunk of the sound stage if you have a 24 or even a 16 bit image to start with. That image electroacoustically couples you with where the image was recorded if those inaudible frequencies are faithfully recorded and played back as a stereo image or greater.

Think of it as a audio hologram.

If an inaudible 25khz audio wave collides with an inaudible 30khz audio wave, an audible 5khz audio wave is produced. This happens thousands of times per second across the whole listening room. You can hear this.

This is what the sound stage is.

Unfortunately this is true. That's why bt is unworkable for high fidelity open air listening systems, it barely has enough for closed listening systems.

Sorry if I made you sad...
[Android Software/Hacking General [Developers Only]] klaberte:
Blackhawk, I am neither sad or mad, and am relieved that you are not as well. Just a spirited discussion. You clearly seem technical enough to be able to set up and do the abx tests I mentioned. You and I both understand the technical arguments for greater than 20 kHz, greater than 16 bit digital audio. (I did a lot of DSP in grad school and in the early part of my career.)

Where we differ is that I just don't think you can hear the difference. I thought I would be able to, but when I did the tests, I completely failed. It is certainly possible that you have better ears than me. If so, I would think you would want to prove it by taking an abx test. But I doubt you, or most people, would pass such a test. Its just human anatomy.
[Android Software/Hacking General [Developers Only]] blackhawk:
Meh, just funning with you. Not mad or sad either.

I like to know what the actual output bitrate my 10+ is really using, other than that it doesn't matter. Again just curiosity.

As I illustrated with a stereo image with 2 or more drivers in open air you can hear the difference even if you can't hear beyond 8khz because of the increased stage presence. In good recordings it's striking even with 2 channels.

However I can still hear the sizzle of the snare drums on a closed system. And mosquitoes.
[Android Software/Hacking General [Developers Only]] dandreye:
Any chance at all to take a Bluetooth trace on it? Wireshark would then tell RTP BW immediately.
[Android Software/Hacking General [Developers Only]] blackhawk:
Thank you, but that's beyond my skillset* but thank you wireshark looks like a useful tool.

Be nice if stock Android easily show the info.

It's always like pulling teeth even running on Pie.

*again there's no non root method for me to alter the bitrate settings that I haven't already done so it remains a dead end for me.
[Android Software/Hacking General [Developers Only]] dandreye:
What's more, as I learned while analysing disassembled stock Oreo Bluedroid code by Broadcomm some idiots at Samsung removed part of AOSP BT logging (into the system log, viewable in Logcat/Catlog) that'd be quite useful for our SBC exercises here.

On BT tracing: worth noting that I ran into BT tracing issues myself even on that stock Oreo ROM - seems like entire AVDTP/A2DP traffic with all those codec and parameter negotiations is completely missing from the bugreport taken in Developer Options. They're apparently trying to hide all those internals.