The test is over. I'm no longer accepting libraries to patch.
SBC XQ Feature is available in LineageOS 15.1 build created on or after the 31st of March 2019, or a 16.0 build created on or after the 13th of May 2019.
Many note low sound quality and lack of high frequencies when using the standard SBC Bluetooth codec, which is supported by all headphones and other Bluetooth devices. A common recommendation to get better sound quality is to buy devices and headphones with aptX or LDAC codecs supported. These codecs require licensing fees, so devices with them are more expensive.
It turns out that the low quality of SBC is caused by artificial limitations of all current Bluetooth stacks and headphones' configuration, and this limitation can be circumvented on any existing devices.
Everyone interested in Bluetooth audio, please take part in high-bitrate SBC compatibility testing on various headphones, receivers, stereo systems, or automotive head units.
If the vast majority of devices work with high bitrates, I will make a patch for Android and send it to AOSP and third-party ROMs, and high quality Bluetooth audio will be available to everyone on any headphones and smartphones, regardless of codecs with licensing fees.
Short technical information about SBC codec
SBC has lots of different parameters that are negotiated during the connection setup phase:
Audio channel type and number: Joint Stereo, Stereo, Dual Channel, Mono;
Number of frequency bands: 4 or 8;
Number of audio blocks in one packet: 4, 8, 12, 16;
Quantization bit allocation algorithm: Loudness, SNR;
Maximum and minimum bit pool used in quantization process: usually 2-53.
The decoder is required to support any combination of these parameters. Encoder may implement only a part of them.
Existing Bluetooth stacks usually negotiate the following profile: Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53. This profile encodes 44.1 kHz audio with a bitrate of 328 kbps.
Bitpool parameter directly affects the bitrate within the same profile: the higher it is, the higher the bitrate, and hence the quality.
However, the bitpool parameter is not bound to a specific profile. The bitrate is also significantly affected by other parameters: audio channel type, number of frequency bands, number of audio blocks. You can increase the bitrate indirectly by negotiating non-standard profiles, without changing the bitpool.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
For example, Dual Channel encodes channels separately, using the entire bitpool for each channel. Forcing the device to use Dual Channel instead of Joint Stereo will get us almost doubled bitrate at the same maximum bitpool, 617 kbps.
To me it feels that bitpool should be an internal variable. It is an A2DP specification design fault that bitpool value is not bound to other codec parameters and only defined as a global value.
These fixed Bitpool and Bitrate values originate from recommended values for high-quality audio. But the recommendation is not an excuse to limit the profile to these values.
A2DP specification v1.2, which was active from 2007 to 2015, requires all decoders to work correctly with bitrates up to 512 kbps:
The decoder of the SNK shall support all possible bitpool values that do not result in the excess of the maximum bit rate. This profile limits the available maximum bit rate to 320kb/s for mono, and 512kb/s for two-channel modes.
Click to expand...
Click to collapse
In the new version of the specification there is no bitrate limitation. It is assumed that modern headphones released after 2015 with EDR can support bitrates up to 730 kbps.
For some reason, all currently tested Bluetooth stacks (Linux (PulseAudio), Android, Blackberry and macOS) have artificial restrictions of maximum bitpool parameter, which directly affects the maximum bitrate. But this is not the biggest problem, almost all headphones also limit the maximum bitpool value to 53.
As I've already seen in my tests, most devices work fine on a modified Bluetooth stack with a bitrate of 507 kbps, without interrupts and crackling. But such a bitrate will never be negotiated under normal conditions, with stock Bluetooth stacks.
How to test on a PC
High bitrate SBC headphone compatibility test is the easiest to perform on the PC with a Bluetooth adapter. I've prepared Ubuntu image with a modified Bluetooth stack, which can be run as in a virtual machine (by connecting Bluetooth adapter as a USB device inside the virtual machine, it also works with the adapters built into the laptops) or by booting from the USB flash drive. This image uses the following profile: Dual Channel, 8 bands, 16 blocks, Loudness, bitpool 2..41, 44.1 kHz, which provides 485 kbps bitrate.
See the attachment in the end of this post.
Running in a VM
Download Virtualbox and Virtualbox Extension Pack: https://www.virtualbox.org/wiki/Downloads;
Install Virtualbox, start it;
Install Extension Pack using File → Preferences → Extensions;
Create new virtual machine: Linux, Ubuntu (64-bit), 1024 RAM. Do not create a HDD.
Navigate to virtual machine settings, in Storage choose Controller: IDE, Empty, press CD icon → Choose virtual optical disk file;
Select downloaded bluetooth-dualchannel-test-ubuntu-18.04.1-desktop-amd64.iso;
Save and close settings window, start virtual machine;
Right-click USB cable icon in the bottom right, select your Bluetooth adapter;
Running on a PC
The image supports BIOS/CSM and UEFI booting.
Burn the image to a USB flash drive using Etcher: https://etcher.io/. This operation will delete all existing files on a USB drive.
Turn off the PC;
Insert USB flash drive, turn on the PC and press boot order button (usually Esc or F12);
Select your USB flash drive.
Performing the test
(optional but recommended) Double click on "Btsnoop Dump" script on the desktop. It will start Bluetooth data capture for later analysis. Do not close terminal window.
Switch the headphones to pairing mode;
Click to the arrow in top right corner, select Bluetooth icon → Bluetooth Settings;
Choose your headphones, wait until pairing is complete and close the window;
Set Ubuntu volume to about 2/3. Also decrease volume using headset buttons as it could be very loud after pairing.
Open "music" folder, play "testrecord1.flac";
(optional but recommended) Close player, close terminal window. This will stop data capture.
(optional but recommended) Open Firefox browser, upload data dump (btsnoop_hci.btsnoop on the desktop) to https://btcodecs.valdikss.org.ru/
You can listen to other music in the music folder, or upload your own;
Post in this topic your headphone model and test results.
There should be no cracklings, audio interruption or other sound distortion in the headphones. If you hear a good high-quality sound, that means your headphones support audio with a bit rate of 485 kbps.
If you upload data to the server, please carefully follow the algorithm above. Especially, if you power off the headphones or disconnect after pairing, it's important to connect to the headphones manually from the bluetooth settings, do not allow auto connection!
How to test on Android device
In order to test from Android smartphone or tablet you need to use modified Bluetooth stack, which requires root privilege.
For regular users
Use PC method if possible.
Create backup before overwriting bluetooth library. Some patched libraries are attached to this post.
Unrestricted/unlimited versions negotiate Dual Channel mode and disable bitrate restriction (617-660 kbit/s will be used). Versions with 482 or 486 prefix negotiate 474-485 kbit/s.
For ROM developers (Android 5-7)
Patchset which increases maximum Bitpool value and adds Bluetooth Dual Channel option is available using the following link:
LineageOS 14.1 (Android 7.1.2)
The following information is outdated and is kept only for historical reasons:
Code:
[b]These modifications are designed only for test and should not be applied to the main ROM repository![/b]
[b]If you're a ROM developer, please provide flashable modified bluetooth library if possible![/b]
These modifications should be applied to stock Android bluetooth stacks Bluedroid (Android 5) and Fluoride (Android 6-7). Qualcomm-modified stack is not supported.
[b]1. Replace Joint Stereo with Dual Channel in standard SBC configuration[/b]
[url="https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/master/btif/co/bta_av_co.c#99"][i]android/platform/external/bluetooth/bluedroid/btif/co/bta_av_co.c:99[/i][/url]
[code]const tA2D_SBC_CIE btif_av_sbc_default_config =
{
BTIF_AV_SBC_DEFAULT_SAMP_FREQ, /* samp_freq */
A2D_SBC_IE_CH_MD_JOINT, /* ch_mode */
A2D_SBC_IE_BLOCKS_16, /* block_len */
A2D_SBC_IE_SUBBAND_8, /* num_subbands */
A2D_SBC_IE_ALLOC_MD_L, /* alloc_mthd */
BTA_AV_CO_SBC_MAX_BITPOOL, /* max_bitpool */
A2D_SBC_IE_MIN_BITPOOL /* min_bitpool */
};
Replace A2D_SBC_IE_CH_MD_JOINT with A2D_SBC_IE_CH_MD_DUAL.
2. Increase Dual Channel priority
android/platform/external/bluetooth/bluedroid/btif/co/bta_av_co.c:411
Code:
if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_JOINT)
pref_cap.ch_mode = A2D_SBC_IE_CH_MD_JOINT;
else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO)
pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO;
else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL)
pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL;
else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO)
pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO;
Move if with A2D_SBC_IE_CH_MD_DUAL to the top.
3. Disable or increase bitrate restriction
Android bluetooth stack has not only bitpool limit, but also bitrate limit, 328 kbit/s. If the headphones support, for example, bitpool 53 for 48 kHz, Android will decrease the bitpool down to fit into 328 kbit/s limit. This will happen AFTER codec negotiation, on the encoding stage, do not take into account bitpool value in Bluetooth SetCapabilities packet.
android/platform/external/bluetooth/bluedroid/btif/src/btif_media_task.c:172
Code:
#define DEFAULT_SBC_BITRATE 328
Replace with 512.
4. (for experiments only) Disable MTU limit.
This is required for bitrates higher than ~580 kbit/s.
btif/src/btif_media_task.c:174
Code:
/* 2DH5 payload size of 679 bytes - (4 bytes L2CAP Header + 12 bytes AVDTP Header) */
#define MAX_2MBPS_AVDTP_MTU 663
[/code]
For ROM developers (Android 8-9)
Patchset which increases maximum Bitpool value and adds Bluetooth Dual Channel option is available using the following links:
LineageOS 15.1 (Android 8.1)
LineageOS 16.0 (Android 9)
AOSP Master (what will eventually become Android 9.1/10)
If you're a ROM developer, please provide flashable modified bluetooth library if possible!
The following information is outdated and is kept only for historical reasons:
1. Add Dual Channel support into A2DP SBC Source
/platform/system/bt/stack/a2dp/a2dp_sbc.cc:55
Code:
/* SBC SRC codec capabilities */
static const tA2DP_SBC_CIE a2dp_sbc_caps = {
A2DP_SBC_IE_SAMP_FREQ_44, /* samp_freq */
(A2DP_SBC_IE_CH_MD_MONO | A2DP_SBC_IE_CH_MD_JOINT), /* ch_mode */
(A2DP_SBC_IE_BLOCKS_16 | A2DP_SBC_IE_BLOCKS_12 | A2DP_SBC_IE_BLOCKS_8 |
A2DP_SBC_IE_BLOCKS_4), /* block_len */
A2DP_SBC_IE_SUBBAND_8, /* num_subbands */
A2DP_SBC_IE_ALLOC_MD_L, /* alloc_method */
A2DP_SBC_IE_MIN_BITPOOL, /* min_bitpool */
A2DP_SBC_MAX_BITPOOL, /* max_bitpool */
BTAV_A2DP_CODEC_BITS_PER_SAMPLE_16 /* bits_per_sample */
};
add A2DP_SBC_IE_CH_MD_DUAL in ch_mode.
2. Replace Joint Stereo with Dual Channel in default config
/platform/system/bt/stack/a2dp/a2dp_sbc.cc:82
Code:
/* Default SBC codec configuration */
const tA2DP_SBC_CIE a2dp_sbc_default_config = {
A2DP_SBC_IE_SAMP_FREQ_44, /* samp_freq */
A2DP_SBC_IE_CH_MD_JOINT, /* ch_mode */
A2DP_SBC_IE_BLOCKS_16, /* block_len */
A2DP_SBC_IE_SUBBAND_8, /* num_subbands */
A2DP_SBC_IE_ALLOC_MD_L, /* alloc_method */
A2DP_SBC_IE_MIN_BITPOOL, /* min_bitpool */
A2DP_SBC_MAX_BITPOOL, /* max_bitpool */
BTAV_A2DP_CODEC_BITS_PER_SAMPLE_16 /* bits_per_sample */
};
Replace A2DP_SBC_IE_CH_MD_JOINT with A2DP_SBC_IE_CH_MD_DUAL.
3. Increase Dual Channel priority
/platform/system/bt/stack/a2dp/a2dp_sbc.cc:1155
Code:
static bool select_best_channel_mode(uint8_t ch_mode, tA2DP_SBC_CIE* p_result,
btav_a2dp_codec_config_t* p_codec_config) {
if (ch_mode & A2DP_SBC_IE_CH_MD_JOINT) {
p_result->ch_mode = A2DP_SBC_IE_CH_MD_JOINT;
p_codec_config->channel_mode = BTAV_A2DP_CODEC_CHANNEL_MODE_STEREO;
return true;
}
if (ch_mode & A2DP_SBC_IE_CH_MD_STEREO) {
p_result->ch_mode = A2DP_SBC_IE_CH_MD_STEREO;
p_codec_config->channel_mode = BTAV_A2DP_CODEC_CHANNEL_MODE_STEREO;
return true;
}
if (ch_mode & A2DP_SBC_IE_CH_MD_DUAL) {
p_result->ch_mode = A2DP_SBC_IE_CH_MD_DUAL;
p_codec_config->channel_mode = BTAV_A2DP_CODEC_CHANNEL_MODE_STEREO;
return true;
}
if (ch_mode & A2DP_SBC_IE_CH_MD_MONO) {
p_result->ch_mode = A2DP_SBC_IE_CH_MD_MONO;
p_codec_config->channel_mode = BTAV_A2DP_CODEC_CHANNEL_MODE_MONO;
return true;
}
return false;
}
Move if with A2DP_SBC_IE_CH_MD_DUAL to the top.
4. Increase bitrate limit
/platform/system/bt/stack/a2dp/a2dp_sbc_encoder.cc:42
Code:
#define A2DP_SBC_DEFAULT_BITRATE 328
Replace with 512.
5. (for experiments only) Disable MTU limit
This is required for bitrates higher than ~580 kbit/s.
/platform/system/bt/stack/a2dp/a2dp_sbc_encoder.cc:47
Code:
#define MAX_2MBPS_AVDTP_MTU 663
[/code]
For advanced users and ROM developers (Android 5-7 binary patch)
Please refer to this post in Russian (use Google Translate): https://4pda.ru/forum/index.php?s=&showtopic=914135&view=findpost&p=76169677
How to capture Bluetooth data dump on Android
Turn off Bluetooth;
In Developer Settings, enable the "Enable Bluetooth HCI snoop log" switch;
Turn on Bluetooth, connect to your headset using Bluetooth menu (this is important! Do not allow auto connection!);
Play short audio sample;
Open developer settings, disable the "Enable Bluetooth HCI snoop log" switch;
There should be /storage/emulated/0/btsnoop_hci.log or /data/misc/bluetooth/logs/btsnoop_hci.log created. If it's missing, open /etc/bluetooth/bt_stack.conf with a text editor and see the path in BtSnoopFileName option.
Upload btsnoop_hci.log to https://btcodecs.valdikss.org.ru/;
Post in this topic your headphone model and test results.
There should be no cracklings, audio interruption or other sound distortion in the headphones. If you hear a good high-quality sound with the patched library, that means your headphones support audio with a bit rate of 512 kbps.
If you upload data to the server, please carefully follow the algorithm above. Especially, if you power off the headphones or disconnect after pairing, it's important to connect to the headphones manually from the bluetooth settings, do not allow auto connection!
Some of the files attached below have no MTU limit patched. Unlocked/unrestricted versions most probably will introduce cracklings.
Tested devices
Devices which support at least 512 kbit/s SBC
1MORE iBFree
JBL Everest 310
JBL Everest 700
JBL T110BT
JBL E55BT
JBL T460BT
JBL Endurance SPRINT (Claim to not support Dual Channel, but work if forced. Does not conform to A2DP specification.)
Skullcandy HESH 3
SoundPEATS Q30
Sony WH-H900N
Sony WI-C400
Sony MDR-1ABT
Sony MDR-ZX770BT
Sony MDR-ZX770BN
Sony MDR-XB650BT
Sony MDR-XB950B1
Sony SBH50
SVEN AP-B570MV
Syllable G600
Bluedio A/Air (Claim to not support Dual Channel, but work if forced. Does not conform to A2DP specification.)
Bluedio T4s (Bitpool max 39. Claim to not support Dual Channel, but work if forced, 462 kbit/s. Does not conform to A2DP specification.)
Bluedio T5 (Claim to not support Dual Channel, but work if forced. Does not conform to A2DP specification.)
Bluedio T6 (Claim to not support Dual Channel, but work if forced. Does not conform to A2DP specification. Adopt Max 97220 chipset.)
Marshall Major II Bluetooth
Overdrive RealForce D1
DEXP BT-210
DEXP BT-220
DEXP BT-250
DEXP BT-260
DEXP BT-280
Edifier W288BT
Edifier W830BT
Nomi BT 211
LeEco Le Sports BT
Xiaomi MI Portable Bluetooth Speaker
Xiaomi Square Box Bluetooth Speaker 2
Sennheiser HD 4.40BT
AKG K845BT
Beyerdynamic Amiron Wireless
Bowers & Wilkins PX
Bowers & Wilkins Zeppelin Wireless
House of Marley Liberate XLBT
Harman Kardon Onyx Studio 4
Harman Kardon Aura Studio 2
QCY QY8
Panasonic RP-BT10
Jaybird X3
Logitech BT Adapter
TP-Link HA100
Xiaomi Mi Bluetooth Audio Receiver
Overfly Portable Bluetooth Receiver
KZ Wireless Bluetooth Module
Excelvan B7
Hagibis X2
Pioneer SE-E7BT
Automotive DAC Lusya bluetooth 4.0 with AK4490, NE5532
Noname automotive head unit (CSR8645 chip)
Sony DSX-A400BT automotive head unit
Devices which support SBC higher than 512 kbit/s
JBL Everest 310 (617-660 kbps)
JBL T110BT (576 kbps)
JBL Endurance SPRINT (573 kbps)
SoundPEATS Q30
DEXP BT-210 (617 kbps)
DEXP BT-220 (617 kbps)
DEXP BT-260 (617 kbps)
DEXP BT-280 (617 kbps)
Sony WI-C400 (576 kbps)
Sony MDR-ZX770BT (617-660 kbps)
Sony MDR-ZX770BN
Marshall Major II Bluetooth (617-660 kbps)
Overdrive RealForce D1 (730 kbps, dual channel, 4 subbands)
Jaybird X3
QCY QY8 (617 kbps)
Edifier W288BT (617 kbps)
Panasonic RP-BT10 (596 kbps)
LeEco Le Sports BT (617 kbps)
Nomi BT 211 (617 kbps)
Xiaomi Mi Bluetooth Audio Receiver (576 kbps)
Overfly Portable Bluetooth Receiver (617 kbps)
Automotive DAC Lusya bluetooth 4.0 with AK4490, NE5532 (576 kbps)
Devices which don't work with higher bitrates or Dual Channel
Harper HB-202 (cracklings; Beken BK3256 chip)
Sony Ericsson MW600 (high frequency distortion, cracklings; device from 2009)
Sony SBH52 (too slow to handle packet rate)
BlitzWolf BW-F2 (no sound)
Overfly mini Bluetooth receiver (no sound)
Why this is important: SBC 328k and 485k vs aptX
Contrary to popular belief of aptX sound quality, in some cases it can produce worse audio quality than SBC with a standard 328k bitrate.
SBC dynamically allocates quantization bits for frequency bands, acting on a "bottom-to-top" basis. If the whole bitrate was used for the lower and middle frequencies, the upper frequencies are "cut off" (silenced).
aptX quantizes frequency bands with the same number of bits constantly, which makes it a constant bitrate codec: 352 kbps for 44.1 kHz, 384 kbps for 48 kHz. It can't "transfer bits" to frequencies that are mostly needed in them. Unlike SBC, aptX will not "cut" frequencies, but will add quantization noise to them, reducing the dynamic range of audio, and sometimes introducing crackles. SBC, on the contrary, "eats the details" - discards the quietest areas.
On average, compared to SBC 328k, aptX makes less distortion in music with a wide frequency range, but on music with a narrow frequency range and a wide dynamic range SBC 328k sometimes wins.
Let us consider a special case, a piano recording. Here's a spectrogram:
The most energy lies in the 0-4 kHz frequencies, and lasts up to 10 kHz.
The spectrogram of the file aptX file looks like this:
Here is SBC 328k:
It can be seen that the SBC 328k periodically completely cut off the range above 16 kHz, and used all available bitrates for ranges below this value. However, aptX introduced more distortions into the frequency spectrum audible by the human ear, which can be seen on the subtracted original spectrogram from the aptX spectrogram (the brighter, the more distortion):
While the SBC 328k has introduced less distortion the signal in the range from 0 to 10 kHz, and the rest has been сut:
Bitrate 485k for SBC was enough to save the entire frequency range, without cutting off the bands.
SBC 485k on this audio sample is much better than aptX in the range of 0-15 kHz, and with a smaller but still noticeable difference - at 15-22 kHz (the darker, the less distortion):
Switching to a high-bitrate SBC, you will get a sound superior to aptX most of the time, on any headphones.
Bro. The concepts sound amazing.
I have Le Max 2 (Oreo). I have attached Bluetooth .so files.
If you patch I will try on Sony Bluetooth system and share with my friends patched files to see how much it works.
Thanks.
rohit3192 said:
Bro. The concepts sound amazing.
I have Le Max 2 (Oreo). I have attached Bluetooth .so files.
If you patch I will try on Sony Bluetooth system and share with my friends patched files to see how much it works.
Thanks.
Click to expand...
Click to collapse
For some reason I can't download your file, always get 404 not found. Another person with LeEco LeMax 2 (x820) contacted me and I made a patch, but only for 32-bit library. Since your archive is >2 MB, I suppose it contains 32 and 64 bit libraries. Please write your exact OS version and build number.
Would you mind to try? Backup your files first, replace 32-bit library with the file from the archive and rename 64-bit library, so it won't be used, and follow the instructions in the second post to capture the dump and upload it to btcodecs.
OK .
I try. Allow me some time.
Yes both libs were in one file. Now sending you separate libs.
rohit3192 said:
OK .
I try. Allow me some time.
Yes both libs were in one file. Now sending you separate libs.
Click to expand...
Click to collapse
Try these.
I have replaced file in /system/lib with permission.
And renamed /lib64 file as instructed.
Bluetooth switch doing nothing.
After renaming lib64 to original name the Bluetooth switch works and connects.
Build no attached.
rohit3192 said:
I have replaced file in /system/lib with permission.
And renamed /lib64 file as instructed.
Bluetooth switch doing nothing.
After renaming lib64 to original name the Bluetooth switch works and connects.
Build no attached.
Click to expand...
Click to collapse
Please try the latest archive. It includes patched 64 bit libraries.
The new patched 64bit file worked.
Tried 486 one only.
Here is Bluetooth log. (Upload was too slow at given link so sending GD link)
Post edited: thanks @ValdikSS a lot.
rohit3192 said:
Here is Bluetooth log. (Upload was too slow at given link so sending GD link)
Click to expand...
Click to collapse
Yes, it worked, the bitrate is 485 kbit/s. Did you hear any cracklings or interruptions?
The audio you played is of low quality. That's probably an MP3 ~160-192 kbit/s?
There is no crackling. Yes mp3 was of low quality that I tested.
Yet sound seems improved. I will need more time to get proper impression. I will post later here.
Also I have spread the word in few telegram channels.
Thanks
@op here you have my lib from Huawei P9 Android 7.0
Can you check and modded to test. I be test on my LG HBS910 with aptx
https://mega.nz/#!G3gR3RrC!yNysYtkk1DhlBk-ec87bIP56aupCwKvfiWM1k32Qy7k
chudy_85 said:
@op here you have my lib from Huawei P9 Android 7.0
Can you check and modded to test. I be test on my LG HBS910 with aptx
Click to expand...
Click to collapse
Patched version has been added to the second post.
This sound enhancement is only for SBC codec, it won't do anything with aptX. You should disable aptX to test patched version.
Hello
I have 1more ibfree sport headphone that supports AAC HD codec only with apple devices as company has mentioned in their site. (https://india.1more.com/collections...ore-ibfree-sport-bluetooth-earphones-with-mic)
As in your post you have mentioned 1more ibfree, that support aptx codec .
My headphone is newer version of ibfree series.
So the problem is in developer setting I can't change to AAC from SBC codec.
It stays to SBC only so I think I can get help from here from you.
So here the link to those .so files
https://mega.nz/#F!tj5AlahL!yCrNHYB-ft-zaJl2uc7kig
Phone - Le Max2 Lineage Oreo 8.1
AdityaDharewa said:
Hello
So the problem is in developer setting I can't change to AAC from SBC codec.
It stays to SBC only so I think I can get help from here from you.
Phone - Le Max2 Lineage Oreo 8.1
Click to expand...
Click to collapse
Please capture a dump and upload it to https://btcodecs.valdikss.org.ru, you'll see all codec information which the device supports.
And by the way, patched libraries for Le Max2 Oreo are already in the second post, give them a try.
ValdikSS said:
For regular users
Send me your bluetooth stack libraries: /system/lib/hw/bluetooth.default.so and /system/lib64/hw/bluetooth.default.so (if it exists).
Click to expand...
Click to collapse
Hmmm those files don't exist on my device (Pixel 2 XL, Pie 9.0 stock OS)
LeifAlbor said:
Hmmm those files don't exist on my device (Pixel 2 XL, Pie 9.0 stock OS)
Click to expand...
Click to collapse
/system/lib/libbluetooth.so and /system/lib64/libbluetooth.so for Android 9.
ValdikSS said:
/system/lib/libbluetooth.so and /system/lib64/libbluetooth.so for Android 9.
Click to expand...
Click to collapse
Done
Related
How to set FM radio over bluetooth (A2DP) ?? please don recommend FMspxxx
================================================================
After few days search search and search,
I found SoundAbout apps is work on system/FM radio over BLUETOOTH, BUT FM is mono and very little sound ,
I don like to use streaming radio, always buffering and reconnect.
under file is audio_policy.conf, how to amend it ????
whether have to provide which files to fixed if I can do 4.2.1 rom
libaudio.a2dp.default.so
libaudiosetting.so
================================================================
#
# Audio policy configuration for generic device builds (goldfish audio HAL - emulator)
#
# Global configuration section: lists input and output devices always present on the device
# as well as the output device selected by default.
# Devices are designated by a string that corresponds to the enum in audio.h
global_configuration {
attached_output_devices AUDIO_DEVICE_OUT_SPEAKER|AUDIO_DEVICE_OUT_EARPIECE
default_output_device AUDIO_DEVICE_OUT_SPEAKER
attached_input_devices AUDIO_DEVICE_IN_BUILTIN_MIC
}
# audio hardware module section: contains descriptors for all audio hw modules present on the
# device. Each hw module node is named after the corresponding hw module library base name.
# For instance, "primary" corresponds to audio.primary.<device>.so.
# The "primary" module is mandatory and must include at least one output with
# AUDIO_OUTPUT_FLAG_PRIMARY flag.
# Each module descriptor contains one or more output profile descriptors and zero or more
# input profile descriptors. Each profile lists all the parameters supported by a given output
# or input stream category.
# The "channel_masks", "formats", "devices" and "flags" are specified using strings corresponding
# to enums in audio.h and audio_policy.h. They are concatenated by use of "|" without space or "\n".
audio_hw_modules {
primary {
outputs {
primary {
sampling_rates 44100
channel_masks AUDIO_CHANNEL_OUT_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_OUT_EARPIECE|AUDIO_DEVICE_OUT_SPEAKER|AUDIO_DEVICE_OUT_WIRED_HEADSET|AUDIO_DEVICE_OUT_WIRED_HEADPHONE|AUDIO_DEVICE_OUT_AUX_DIGITAL|AUDIO_DEVICE_OUT_ANLG_DOCK_HEADSET|AUDIO_DEVICE_OUT_DGTL_DOCK_HEADSET|AUDIO_DEVICE_OUT_ALL_SCO|AUDIO_DEVICE_OUT_FM_TX|AUDIO_DEVICE_OUT_DEFAULT
flags AUDIO_OUTPUT_FLAG_PRIMARY
}
}
inputs {
primary {
sampling_rates 8000|16000|32000|44100|48000
channel_masks AUDIO_CHANNEL_IN_MONO|AUDIO_CHANNEL_IN_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_IN_COMMUNICATION|AUDIO_DEVICE_IN_AMBIENT|AUDIO_DEVICE_IN_BUILTIN_MIC|AUDIO_DEVICE_IN_WIRED_HEADSET|AUDIO_DEVICE_IN_AUX_DIGITAL|AUDIO_DEVICE_IN_AUX_DIGITAL2|AUDIO_DEVICE_IN_VOICE_CALL|AUDIO_DEVICE_IN_BACK_MIC|AUDIO_DEVICE_IN_ALL_SCO|AUDIO_DEVICE_IN_FM|AUDIO_DEVICE_IN_DEFAULT
}
}
}
a2dp {
outputs {
a2dp {
sampling_rates 44100
channel_masks AUDIO_CHANNEL_OUT_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_OUT_ALL_A2DP
}
}
}
usb {
outputs {
default {
sampling_rates 44100
channel_masks AUDIO_CHANNEL_OUT_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_OUT_ALL_USB
}
}
}
r_submix {
outputs {
r_submix {
sampling_rates 44100|48000
channel_masks AUDIO_CHANNEL_OUT_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_OUT_REMOTE_SUBMIX
}
}
inputs {
r_submix {
sampling_rates 44100|48000
channel_masks AUDIO_CHANNEL_IN_MONO|AUDIO_CHANNEL_IN_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_IN_REMOTE_SUBMIX
}
}
}
}
I think its not possible since The headphone wire normally works AS antenna for The fmradio and With BT u dont have a good signal thats why u hear mono and very low volume
ref : http ://blog.osakana.net/archives/3046
Notepad OSAKANA TAROIt is the site to go to the main someting that technical
Function of radio-related chip that MediaTek MT6628 of
Posted by Osakanataro 9 January 18, 2012 on Leave a Comment (1) Go to comments
"In July function of radio-related chip that MediaTek MT6620 of in ", I wrote an article about that MT6620 chip that is responsible for functions of the radio around the MTK made.
Then, " MTK MT6588/MT6583 appeared plan? early 2013 according to the table that you used in the article "and, it was described in the MT6588 generation, peripheral chips that MT6628 also be used.
More so had not been published, I was not in material, but full details had come out.
As a product, the two types of "MT6628Q" and "MT6628T".
- MT6628Q Wireless Connectivity 4-in-1 combo for SP and Tablet Market
- MT6628T Wireless Connectivity 3-in-1 combo for SP and Tablet Market
If you write easily the difference between the two spec 2
4in1 with wireless LAN / Bluetooth / GPS / FM radio: MT6628Q
3in1 with wireless LAN / Bluetooth / FM radio: MT6628T
thing. Pin arrangement is the same for both, it seems possible replacement.
(User is that, replace indeed it is impossible, but ...)
However, I etc. Talking about Chinese Sumafo how much, and ... but I want to think that it is to no GPS on a smartphone nowadays
main target of MT6628T it will be to such such as tablet in the home for possibly.
In, the old MT6620 and MT6628Q / MT6628T I tried to compare the but, is that there is likely to be degenerate on spec listed, it is a little subtle.
MT6628 reinforcement
for and wireless LAN, and Wifi Display and HotSpot 2.0 support
Part may have degenerated in MT6628
(StrikethroughPart of is) not listed in MT6628
LAN or wireless 802.11a/ B / g / n support
· GPS (U.S.) /Galileo (EU)/ Support (satellite-based augmentation system is operating in each country) QZSS (Japan Quasi-Zenith Satellite System) / SBAS
-Function corresponding to the spurt in Bluetooth voice of FM radio called "FM over Bluetooth"
·It seems to be the position information ensure low power consumption by the mechanism of MediaTek called "AlwaysLocate"
MT6620/MT6628 intersection
· Wi-Fi CERTIFIED Passpoint, Wi-Fi Direct support
· Bluetooth 3.0 + HS, and, Bluetooth 4.0 Low Energy support
· GPS sensitivity-165dBm
of America and the RDS (EU FM data broadcasting · FM radio RBDS) correspondence
there is a packet loss concealment system for the packet-voice? "PLC (Packet Loss Concealment) technology for superior audio quality"
● description of the MT6620 page
description of the page of △ MT6628Q
description of the page ■ MT6628T
● Low power, Small size and high performance WLAN / Bluetooth / GPS / FM Solution
△ Low power, Small size and high performance WLAN / Bluetooth / GPS / FM Solution
■ Low power, Small size and high performance WLAN / Bluetooth / FM Solution
● WLAN 802.11 a / b / g / N dual band Single stream (20/40MHz) with dual band LNA and 2.4GHz PA Integration
△ WLAN 802.11 b / g / N dual band Single stream (20/40MHz) with LNA and PA Integration
■ WLAN 802.11 b / g / n dual band single stream (20/40MHz) with LNA and PA integration
● Bluetooth 3.0 + HS and V4.0 Low Energy Support Integration with PA
△ Bluetooth 3.0 + HS and V4.0 Low Energy Support Integration with PA
■ Bluetooth 3.0 + HS and V4.0 Low Energy Support Integration with PA
● Support GPS / Galileo / QZSS / SBAS with-165dBm tracking Sensitivity
△ Support GPS / QZSS / SBAS with-165dBm tracking Sensitivity
● FM Tx / Rx with RDS / RBDS Support
△ FM Rx with RDS / RBDS Support
■ FM Rx with RDS / RBDS Support
● Support WAPI hardware encryption and Wi-Fi Direct
△ Support WAPI hardware encryption and Wi-Fi Direct, Display and HotSpot2.0
■ Support WAPI hardware encryption and Wi-Fi Direct, Display and HotSpot2.0
● Support FM over Bluetooth
● PLC (Packet Loss Concealment) Technology for Superior audio quality
△ PLC (Packet Loss Concealment) Technology for Superior audio quality
■ PLC (Packet Loss Concealment) Technology for Superior audio quality
● Advanced AlwaysLocateTM location awareness technology with ultra low power consumption
● Flexible host interfaces include Single Support SDIO interface for all wireless functions
△ Flexible host interfaces include Single Support SDIO interface for all wireless functions
■ Flexible host interfaces include Single Support SDIO interface for all wireless functions
■ Pin-to-pin compatible with MT6628Q
Hey has anyone gotten UHQ to work on bluetooth? I just got in the update and it enables when I plug my headphones into the phone but not when connected via BT. Thanks
Sent from my SM-G920V using XDA Free mobile app
whatnow275 said:
Hey has anyone gotten UHQ to work on bluetooth? I just got in the update and it enables when I plug my headphones into the phone but not when connected via BT. Thanks
Sent from my SM-G920V using XDA Free mobile app
Click to expand...
Click to collapse
Not entirely sure if BT can support the bitrate requirement for UHQ. BT isn't really a data heavy protocol.
Sent from my iPhone using Tapatalk
LNJ said:
Not entirely sure if BT can support the bitrate requirement for UHQ. BT isn't really a data heavy protocol.
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
Okay thanks. Yeah I know BT isnt great for HQ but I guess I was under the impression that the tweaks would work on either.
Sent from my SM-G920V using XDA Free mobile app
whatnow275 said:
Okay thanks. Yeah I know BT isnt great for HQ but I guess I was under the impression that the tweaks would work on either.
Sent from my SM-G920V using XDA Free mobile app
Click to expand...
Click to collapse
To use UHQ on bluetooth connectivity, you must have a compatible Bluetooth Headphone. Check out Samsung Level On Wireless Pro.
Samsung Level on Pro with S7 EDGE
I am currently listening to 24\192 tracks on my S7 edge with PowerAMP alpha and a bluetooth attached Level on Pro. I had my doubts when I read the specs but it is extremely likely that it works for this combination of hardware and software . UHQ via Bluetooth does work.
Galaxy S6 (S6 Edge, Edge+) and S7 (S7 Edge) support UHQ-BT codec developed by Samsung (don't mix with Samsung UHQ upscaler used in stock Music application). This codec allows audio transmittion via Bluetooth 4.0 at a pretty high resulution: 24 bit / 96 kHz (2 channels stereo). In order to be able to use this feature you must use Bluetooth audio device, which supports this codec, for example, headphones Samsung Level series. In order to enable UHQ-BT you need to download the application Samsung Level from Google Play Market and make sure that "UHQ" is enabled. 24 / 96 is the TOP possible limit of UHQ-BT codec for a pair S7 (S7E) + Level headphones. Of course it also depends on the audio file (stream) you're trying to play. If the file itself has low audio resolution with high compression then you cannot get high audio quality. The best audio quality will be when listening to audio files in lossless format (such as flac) with resolution 24 bit / 96 kHz. But there's also a question of how such high resolution was created. One thing is it was made from the original studio recording (made in 24, 36 or 48 bit resolution on professional equipment). And the other thing is if the source for lossless 24/96 audio file was a crappy mp3. A special case would be some vinyl-rip made by an enthusiast on some high-end analog - digital pair. You can find them with resolution as high as 24/192. But most of the time you get some background noise and vinyl crackle. So, the point of such high resolution for vinyl rips in the first place is rather doubtful in my opinion... Also, since UHQ-BT top capability is 24/96 audio resolution, there's no point in using 24/192 for our pair (S7 + Level headphones) UHQ-BT will downscale it to its 24/96 anyway... Other high-res BT codecs available: aptX HD, developed by Qualcomm, which supports HD audio with resolution 24/44, which is a little lower than UHQ-BT. Standard aptX supports CD-audio with resolution up to 16/44, which is even lower. Samsung Galaxy S6 (S6E) and S7 (S7E) support aptX, but do not support aptX HD. If you have a BT audio devise, which supports aptX and are unwilling to get Samsung Level series headphones (Level U, Level U Pro, Level U Pro ANC, Level On, etc...) then aptX supported quality with 16/44 resolution is the highest possible that you'll get. And if your headphones do not support aptX then you will get even lower resolution. The bottomline is get Samsung Level series headphones, if you want to get the highest BT wireless audio quality.
Now, as far as Samsung UHQ upscaler, which is built-in in the Samsung stock Music application, this is a feature, which increases audio resolution programmably. This helps to get the audio sound a little "more smooth" compared with original low-res quality. It removes to certain extent the "digitalness" of the sound, "making connection" between sound "dots" smoother. But it cannot make up high frequency sounds between dots, which may be lost due to low resolution and/or high compression. It simply "doesn't know" they existed.
Hey guys. I swear when I say this that I had a S6 for 2 years and the old samsung music app allowed to enable the UHQ mode even when connected to standard Bluetooth headphones and scrappy speakers started aounding great. In fact I was just surprised at how much of a difference it made. But I updated the app and since then have never gotten it to work over Bluetooth. It still works for wired headphones. But honest to good this feature actually worked and made no difference to which speaker it was connected to.
So I am pretty sure there must be a way to get it to work it is definitely a software matter. I am sure some of you smart folks can figure it out.
What if?
skg27 said:
Galaxy S6 (S6 Edge, Edge+) and S7 (S7 Edge) support UHQ-BT codec developed by Samsung (don't mix with Samsung UHQ upscaler used in stock Music application). This codec allows audio transmittion via Bluetooth 4.0 at a pretty high resulution: 24 bit / 96 kHz (2 channels stereo). In order to be able to use this feature you must use Bluetooth audio device, which supports this codec, for example, headphones Samsung Level series. In order to enable UHQ-BT you need to download the application Samsung Level from Google Play Market and make sure that "UHQ" is enabled. 24 / 96 is the TOP possible limit of UHQ-BT codec for a pair S7 (S7E) + Level headphones. Of course it also depends on the audio file (stream) you're trying to play. If the file itself has low audio resolution with high compression then you cannot get high audio quality. The best audio quality will be when listening to audio files in lossless format (such as flac) with resolution 24 bit / 96 kHz. But there's also a question of how such high resolution was created. One thing is it was made from the original studio recording (made in 24, 36 or 48 bit resolution on professional equipment). And the other thing is if the source for lossless 24/96 audio file was a crappy mp3. A special case would be some vinyl-rip made by an enthusiast on some high-end analog - digital pair. You can find them with resolution as high as 24/192. But most of the time you get some background noise and vinyl crackle. So, the point of such high resolution for vinyl rips in the first place is rather doubtful in my opinion... Also, since UHQ-BT top capability is 24/96 audio resolution, there's no point in using 24/192 for our pair (S7 + Level headphones) UHQ-BT will downscale it to its 24/96 anyway... Other high-res BT codecs available: aptX HD, developed by Qualcomm, which supports HD audio with resolution 24/44, which is a little lower than UHQ-BT. Standard aptX supports CD-audio with resolution up to 16/44, which is even lower. Samsung Galaxy S6 (S6E) and S7 (S7E) support aptX, but do not support aptX HD. If you have a BT audio devise, which supports aptX and are unwilling to get Samsung Level series headphones (Level U, Level U Pro, Level U Pro ANC, Level On, etc...) then aptX supported quality with 16/44 resolution is the highest possible that you'll get. And if your headphones do not support aptX then you will get even lower resolution. The bottomline is get Samsung Level series headphones, if you want to get the highest BT wireless audio quality.
Now, as far as Samsung UHQ upscaler, which is built-in in the Samsung stock Music application, this is a feature, which increases audio resolution programmably. This helps to get the audio sound a little "more smooth" compared with original low-res quality. It removes to certain extent the "digitalness" of the sound, "making connection" between sound "dots" smoother. But it cannot make up high frequency sounds between dots, which may be lost due to low resolution and/or high compression. It simply "doesn't know" they existed.
Click to expand...
Click to collapse
What if I have the S7 and Samsung Level wireless headphones along with the Samsung Level App and the uhq upscaler still is not accessible?
Hi,
Samsung's own UHQA BT audio codec, such as APTx HD or LDAC, has a link bandwidth of 24/96 (512 kbps), but when I connected my Level u pro to my S7 (Exynos) and check it from the developer's menu, it connect with scalable audio codec 16/44. (256 kbps). And I can not change it. in this case 24/96 flac music quality is reduced to cd. Can someone who knows explain?
CyanogenMod 13 is a free, community built distribution of Android 6.0.1 (Marshmallow) which greatly extends the capabilities of your phone.
This is the unofficial Build of CM 13 for Jiayu S3 plus (not advanced or basic), with mt6753 soc
Code:
#include
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Installation Instructions:
Download rom from here: https://www.facebook.com/MediatekAndroidDevelopers/
OR from xda DevDB (DOWNLOAD Tab)
Download Gapps from OpenGapps: http://opengapps.org/, choose Arm64 and Android 6.0
boot to recovery
wipe data if you are not coming from CM13.0 already
install rom and gapps
reboot
XDA:DevDB Information
Cyanogenmod for Jiayu S3 plus, ROM for all devices (see above for details)
Contributors
DerTeufel1980, superdragonpt, fire855
Source Code: https://github.com/MediatekAndroidDevelopers
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.10.x
ROM Firmware Required: custom recovery installed
Version Information
Status: Stable
Created 2016-07-26
Last Updated 2016-07-26
Reserved
Reserved
Q: After ROM boot up, I'm getting SetUP wizard errors / other Gapps FC / Black screen on first boot, why ?
A: On marshmallow based Roms, you need to flash ROM and gapps at the same time
TWRP even allows you to flash multiple .zip files
Q: Why no Mediatek Engineering Menu?
A: Its Mediatek proprietary, ugly , not needed on our builds.
Relevant features used on Mediatek E. Menu have been ported to our builds already using aosp / our implementations ( Sensors calibration , Band Mode, etc)
Q: Do we get The Fast Charge you guys made on Lollipop RC's ?
A: Yes, Fast Charge implementation was implemented on our MM builds
Q: App "x" is not working, why?
A: First make sure the app works under Marshmallow
Q: Something wrong with my Bluetooth, can't connect /pair with my "x" device , car-BT
A: Bluetooth should be backwards compatible , some OEMs don't also follow some guidelines , surely can be improved.
Post your BT model, Car model and year to help us out determining compatibility issues
Woot! Glad to see this up and running Thanks for all the support!
Full CM13 Android in Mediatek phone. Thank you
edit: fixedd
Hi, first of all I would like to say thank u for all your hardwork
I have came across on the specifications page for Mediatek's MT6753 well which was our chipset anyway.
http://www.mediatek.com/en/products/mobile-communications/smartphone1/mt6753/
The CPU clock speed stated on the page was 1.5ghz. Ours was max clocked at 1.3ghz?
Is there any possibility, (not sure if our mtk kernel source is open) that we could get a speedboost, a step up of 200mhz for our cpu?
Or was the 1.5ghz version is already stable and has a chance to boost it up to MT6572's 1.7ghz as well.
I would be glad if anyone can enlighten me about this. Thank you.
Thankyou!!!!
@superdragonpt
Not sure if this is the right thread to report issues of the ROM.
1. Bluetooth not pairing with car. It can detect the headunit but when I try to pair after i enter the pin it fails. I am using the headunit for mitsubishi mirage 2013
Mirage CNE-6515-N HU Specs:
Main Amplifier:
Power Output: 20 Watts RMS x 4 channels into 4-ohms @ < 10 % THD+N
S/N Ratio: 70 dBA below reference. (Ref.: 1 Watt, 4-ohms)
Max Power: 40 x 4 watts into 4-ohms, all channels driven
Frequency Response: 20 Hz to 20 kHz -3dB Aux input used as source reference
3 Band Equalizer (Treble, Mid, Bass)
Reference Supply Voltage: 14.4 VDC
DVD/CD Player:
Compatible Formats: DVD-R, , DVD-RW, DVD+R, DVD+RW, CD-R, CD-RW, CD-DA, MP3, WMA, HDCD, SVCD,VCD, MPEG, JPEG, MP3/WMA burned into a DVD+RW or DVD-RW and CD-R/RW
S/N Ratio: 85 dBA
Dynamic Range: > 95 dB
Frequency Response: 20 Hz to 20 kHz, -3dB
Channel Separation: > 60dB @ 1 KHZ
D/A Converter(s): 6-channels high performance 24-bit, 192 kHz, multi-bit Sigma Delta modulation. DAC supports sample rates from 8-192 kHz.
Electronic Skip Protection (ESP): DVD: 2-3 sec, CD-DA: 10 sec., MP3: 100 sec., WMA: 200 sec. (ESP time approximate)
Mechanical vibration stability: 10-200Hz, X/Y/Z direction: 1.0G
Video Section:
Format: NTSC, PAL (auto-detect)
Output: 1Vp-p (75-ohm), buffered
Input: 1Vp-p (75-ohm)
FM Tuner Section:
Tuning Range: 87.5 MHz - 107.9 MHz
Mono Sensitivity (-30dB): 10 dBu
Quieting Sensitivity (-50dB): 15 dBu
Alternate Channel Sensitivity: 70 dB
S/N Ratio @ 1KHz: 58 dB
Image Rejection: 60 dB
Stereo Separation @ 1 KHz; 30dB
Frequency Response: 30Hz - 15 KHz, -3 dB
AM Tuner Section:
Tuning Range: 530 kHz - 1710 kHz
Sensitivity (-20dB): 20 dBu
S/N Ratio @ 1KHz: 50 dB
Image Rejection: 60 dB
Frequency Response: 50Hz - 2 KHz, -3 dB
Monitor Section:
Screen Size: 6.2" (Measured diagonally)
Screen Type: TFT Digital Display active matrix
Response Time: 30 ms rise time, 50 ms fall tim/Compositee resolution, DVD
Video in: 280,280 sub pixels, 1200 (W) x 234 (H)
Built-in Navigation (Via Micro SD Card)
SD Card: Micro SD
GPS
SiRF Prima 600MHZ CPU, Advanced ARM 11 Architecture
256 MB Nand Flash
256 MB DDR-400MHz RAM
Windows CE 6.0
USB
High-Speed USB 2.0
Bluetooth:
Hands-Free, Phonebook, Recent Calls (Dialed, Missed, Received) Synchronize, Caller ID and Audio Streaming, Mobile Phone
TPMS Ready (optional)
General:
Auxiliary Input impedance: 10 K-ohms
Power Supply: 10.5 to 16 VDC, negative ground
Fuse: 10-amp, mini ATm type
DN chassis dimensions : 7"x7"x 2" (178mm x 178mm x 100mm)
2. When SD card is used as "Internal Storage" and app is installed at SD card, every time I reboot all the shortcut icon disappears in Home Screen.
3. FB Messenger hangs when uploading pictures. Workaround grant permissions via Settings > App > Messenger
makona said:
@superdragonpt
Not sure if this is the right thread to report issues of the ROM.
1. Bluetooth not pairing with car. It can detect the headunit but when I try to pair after i enter the pin it fails. I am using the headunit for mitsubishi mirage 2013
Mirage CNE-6515-N HU Specs:
Main Amplifier:
Power Output: 20 Watts RMS x 4 channels into 4-ohms @ < 10 % THD+N
S/N Ratio: 70 dBA below reference. (Ref.: 1 Watt, 4-ohms)
Max Power: 40 x 4 watts into 4-ohms, all channels driven
Frequency Response: 20 Hz to 20 kHz -3dB Aux input used as source reference
3 Band Equalizer (Treble, Mid, Bass)
Reference Supply Voltage: 14.4 VDC
DVD/CD Player:
Compatible Formats: DVD-R, , DVD-RW, DVD+R, DVD+RW, CD-R, CD-RW, CD-DA, MP3, WMA, HDCD, SVCD,VCD, MPEG, JPEG, MP3/WMA burned into a DVD+RW or DVD-RW and CD-R/RW
S/N Ratio: 85 dBA
Dynamic Range: > 95 dB
Frequency Response: 20 Hz to 20 kHz, -3dB
Channel Separation: > 60dB @ 1 KHZ
D/A Converter(s): 6-channels high performance 24-bit, 192 kHz, multi-bit Sigma Delta modulation. DAC supports sample rates from 8-192 kHz.
Electronic Skip Protection (ESP): DVD: 2-3 sec, CD-DA: 10 sec., MP3: 100 sec., WMA: 200 sec. (ESP time approximate)
Mechanical vibration stability: 10-200Hz, X/Y/Z direction: 1.0G
Video Section:
Format: NTSC, PAL (auto-detect)
Output: 1Vp-p (75-ohm), buffered
Input: 1Vp-p (75-ohm)
FM Tuner Section:
Tuning Range: 87.5 MHz - 107.9 MHz
Mono Sensitivity (-30dB): 10 dBu
Quieting Sensitivity (-50dB): 15 dBu
Alternate Channel Sensitivity: 70 dB
S/N Ratio @ 1KHz: 58 dB
Image Rejection: 60 dB
Stereo Separation @ 1 KHz; 30dB
Frequency Response: 30Hz - 15 KHz, -3 dB
AM Tuner Section:
Tuning Range: 530 kHz - 1710 kHz
Sensitivity (-20dB): 20 dBu
S/N Ratio @ 1KHz: 50 dB
Image Rejection: 60 dB
Frequency Response: 50Hz - 2 KHz, -3 dB
Monitor Section:
Screen Size: 6.2" (Measured diagonally)
Screen Type: TFT Digital Display active matrix
Response Time: 30 ms rise time, 50 ms fall tim/Compositee resolution, DVD
Video in: 280,280 sub pixels, 1200 (W) x 234 (H)
Built-in Navigation (Via Micro SD Card)
SD Card: Micro SD
GPS
SiRF Prima 600MHZ CPU, Advanced ARM 11 Architecture
256 MB Nand Flash
256 MB DDR-400MHz RAM
Windows CE 6.0
USB
High-Speed USB 2.0
Bluetooth:
Hands-Free, Phonebook, Recent Calls (Dialed, Missed, Received) Synchronize, Caller ID and Audio Streaming, Mobile Phone
TPMS Ready (optional)
General:
Auxiliary Input impedance: 10 K-ohms
Power Supply: 10.5 to 16 VDC, negative ground
Fuse: 10-amp, mini ATm type
DN chassis dimensions : 7"x7"x 2" (178mm x 178mm x 100mm)
2. When SD card is used as "Internal Storage" and app is installed at SD card, every time I reboot all the shortcut icon disappears in Home Screen.
3. FB Messenger hangs when uploading pictures. Workaround grant permissions via Settings > App > Messenger
Click to expand...
Click to collapse
1- Known issue, thanks for the BT unit details
2- already answered
3- seems you find the cause, FB apps sucks... Thank them
Sorry guys but what is this?
http://www.needrom.com/download/s3-cm13-0/
It's baptized CM13. 0 from JiaYu.de for S3plus.
Is it other Rom, or someone tries to play it "smart" to the community?
TapaTalk and JiaYu S3 with Android MM!
Having used this for a few days now I love it however I have discovered one bug and one suggestion for better quality of life.
Bug: The aeroplane mode in the power menu (press and hold power button) doesn't work. The tile in the drop down menu still works fine, just the power menu one doesn't.
Quality of Life: Currently there is no way of disabling both sims, one always has to be enabled. Not a big deal for most people, but as someone who travels between countries quite frequently, it would be nice to be able to switch one sim off before putting on the other to avoid any possible roaming charges.
Thanks again for all the support, I was also wondering what version of Xposed would work with CM13?
Regards,
Hey, sorry, I missed your pm.
I need to check airplane mode.... Didn't notice yet.
The other thing isn't meant to be done this way in aosp. I may take a look at it as well, but I can't promise...
The M.A.D. Team
DerTeufel1980 said:
Hey, sorry, I missed your pm.
I need to check airplane mode.... Didn't notice yet.
The other thing isn't meant to be done this way in aosp. I may take a look at it as well, but I can't promise...
The M.A.D. Team
Click to expand...
Click to collapse
No bother I only noticed the airplane mode thing when I was trying to activate it boarding my flight haha
Wow, so this is what you meant when you said
DerTeufel1980 said:
Yeah, I started working for a German section of Chinese smartphone manufacturer (jiayu.de). Didn't have time anymore....
Click to expand...
Click to collapse
Good job anyways!
Update:
https://www.facebook.com/MediatekAndroidDevelopers/
Build 2 : 20160810
Source Synced ( (including Security Updates )
Fixed: Bluetooth (headset , car-BT)
Fixed: Internal Android VPN Client (tested on PPPT protocol)
Fixed Wi-Fi (random connection drops)
Added option to select 2.4 or 5Ghz Wifi frequency to advanced wifi options
Fixed FMRadio (merged previous patch)
Rom link on xda DevDB as well
cheers
Latest twrp recovery, compiled from source:
https://www.androidfilehost.com/?fid=24591000424954599
- fix: mounting adoptable storage
- fix: mounting encrypted devices
The M.A.D. Team
still hoping for an update for this rom Found bugs: Music playback lag and video playing lags.. can't play 1080p videos
Everything is perfect but the BT-CAR....
Its a Citroen C-Elysée 2014
Does anyone know the audio output in this device, I am using power amp media player and need to know if our device supports higher sampling and bit rate, if so how to enable it.
It supports up to 192 kHz - but - it forces the USB-C audio path to 96 kHz no matter what. Don't let the numbers fool you, if you're an audiophile you're going to be disappointed, everything sounds like mud.
The only app that the operating system is not stepping on is USB Audio Player Pro - it bypasses the operating system and provides a bit perfect path from the audio file to the USB output.
If you have an external DAC/amp and good headphones you're going to find bit-perfect 44.1 kHz sounds far better than any up-sampling.
Far better.
(I have no affiliation with USB Audio Player Pro or the company or people behind it. I just like music to sound like it's supposed to, within the technology limits given during production.)
Hi, I am planning to get an external DAC for my Honor View 10 but I read contradictory posts in several forums. With the stock EMUI, does USB audio really work?
Hello, I'm going to present to you a method to enable hi-res on the DAC of the Xiaomi Redmi Note 9' family.
The procedure will allow to you to use the full potential of the WCD9385 DAC present (at least) in the Snapdragon 720G.
Indeed, this chip can go up to 32 bits @ 192Khz for PCM stream and can decode natively DSD. Moreover, this chip have a THD+N (Total Harmonics Distortion + Noise) at a level of -108dB, but all audio tests of Xiaomi's phones mesures a THD+N about ~ -96dB, which is the noise floor of 16bits, logic cause by default, this chip is configured to only output in 16 bits mode.
I have setup, tested and experimenting myself on my own phone (Redmi Note 9 Pro - Global Version - MIUI 12.0.2.0 QJZMIXM) this method.
Due to some ROM similarity with other smartphone models in Xiaomi, it will probably works with other smartphones than the Note 9's family, but i will probably need some adjustments if your phone use a different DAC or scheme of audio configuration files.
Before anything :
I'm not responsible of any damage, malfunction or brick that you can do by applying the method. In general, if you don't know what are you doing, just don't do it !
Click to expand...
Click to collapse
Pre-requests :
1) Install ADB, Fastboot and Google ADB Drivers (if you are on Windows)
2) You need to unlock bootloader with Mi-Flash-Unlock (THIS WILL WIPE ALL YOUR PERSONAL DATA, MAKE A SAVE BEFORE STARTING ANYTHING !)
3) Install TWRP for Redmi Xiaomi Note 9
4) You need to root your smartphone with Magisk and install the boot image in fastboot mode that it will give to you.
5) Install ABD_ROOT and ENABLE_ENG Magisk's modules (it will give you the possibility to get root access in ADB) and turn them on for the next device reboot in Magisk App
6) Install MakeSysRW in TWRP (without it we can't remount /vendor partition in Read-Write, and can't touch system's files)
7) Strongly recommanded but not necessary : install Sample Rate Checker from Google Play (with this tool, you can check if the DAC has correctly been set in "HI-RES" mode)
Click to expand...
Click to collapse
Get your phone tuned for Hi-RES :
1) One all of those pre-requests are effectives, you need to get a terminal with adb working (smartphone connected to your PC and debug mode activated) and type :
adb shell mount -o remount,rw /vendor
If you get no errors, you just mounted the partition /vendor on your phone in Read-Write mode, this will allow you to get to the next step, otherwise, i strongly recommand to you to check if you have correctly done all the pre-requests i have described.
2) The next step will save the current audio configuration of your phone (in case you want to return to it for some reasons), still in a terminal window, type :
Code:
adb pull /vendor/etc/audio/audio_policy_configuration.xml ./saved_audio_policy_configuration.xml
adb pull /vendor/etc/audio_io_policy.conf ./saved_audio_io_policy.conf
This will download from your smartphone to your computer the current audio configuration files and save them under "saved_audio_policy_configuration.xml" and "saved_audio_io_policy.conf" in your current directory.
3) Now we will upload configurations files that i've tuned myself, in first case for my personal use.
What changes I've made from the OEM configuration ?
PRIMARY_OUTPUT was in 16 bits @ 48kHz => changed to 24bits @ 192 Khz
RAW_OUTPUT was in 16 bits @ 48 Khz => changed to 24 bits @ 192 Khz
DEEP_BUFFER was in 24bits @ 48 Khz => changed to 24bits @ 192 Khz
Wired Headset, Wired Headphones and Line comes from 16 bits @ 48 Khz, have all been tuned to 24 bits @ 192 Khz
Moreover, i have not touched the integrated speakers because they will not profit to go into 24 bits mode or with an higher sampling rate, and you will get more energy saving by let them as they currently are.
Click to expand...
Click to collapse
If you check the configuration, you will see at points that I tuned this : samplingRates="48000, 96000,192000"
EDIT 22-04-2021 - Few hours after the first release :
I have done this to let Android choose by it's own the sampling rate, because i have seen some sort of clipping on LINE output with OGG (vorbis) files (I assume it will be the same with destructive formats, such as MP3, but it's at least with OGG files) at max volume with very loud musics, i thinks if you set strict resampling at 96 or 192Khz, due to fast algorithms in Android Audio, it will generate some sort of distortion and, if your music is loud enough (and you are at the max volume), it will go over 0dB and clip. So I've maintained sampling rate at 48Khz, and it seems to be well, but if you have some clipping, please tell me in your reply, i will investigate further.
The clipping was effectively done by a resampling mismatches with two configurations files :
audio_policy_configuration.xml (the one that I modified originally)
audio_io_policy.conf
Sampling rates mismatches in audio_io_policy.conf because I left them to the OEM configuration, now it's fixed.
Click to expand...
Click to collapse
You can get my configuration file in the files attached to this post, unzip the files in the current directory where ADB running, then send them to your device :
Code:
adb push ./audio_policy_configuration.xml /vendor/etc/audio/audio_policy_configuration.xml
adb push ./audio_io_policy.conf /vendor/etc/audio_io_policy.conf
This command will overwrite your current configuration files, once again, please be sure to have saved OEM configuration file on your PC !
4) Reboot your phone, and enjoy ! Now you can check with Sample Rate Checker the configuration, you will see something like this (it can be slithly different depending on what is plugged to your phone when you're start the app, in my case i have plugged my phone to an amplifier, so LINE_ANALOG has appears):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
As you can see, AudioManager is in 192Khz mode, BUILTIN_EARPIECE correspond to the front top speaker usesed for private communications, and BUILTINT_SPEAKER is the bottom speaker, both of them have remain untouched.
The most interesting is LINE_ANALOG, corresponding to the phone plugged to a LINE output (a high impedance receiver, such as an amplifier), you can see the different Sample Rates supported, up to 192Khz, and Encodings is ENCODING_PCM_FLOAT corresponding to 24 bits (you can compare it with BUILTIN_EARPIECE and BUILTIN_SPEAKER that they are in 16bits mode).
EDIT : i can't attach the file to my post, anyway i sent it to mediafire and there is the download link
Download the Audio Configuration files tuned for HI-RES
If you have any comments, any remarks or want help, do not hesitate to ask.
22/04/2021 - Few hours after the first post :
I have discovered that the mysterious clipping isn't present when i plug/unplug the phone for few seconds, before appearing.
After some research, try and retries, I've found the problem : the file audio_io_policy.conf
In this file is listed all outputs present in the audio_policy_configuration.xml, but i found that all outputs have a fixed 48 kHz sample rate, which don't match with the concatenated ones in the tuned file.
Concretely, internally the sample rates don't matches, and streams (over)sampled above 48 KHz are some sort of clipped.
So I have concatenated samples also in audio_io_policy.conf, and now it works well with all types of musics.
The first post will be edited with modifications that you need to do with the file audio_io_policy.conf
06/13/2021 :
Xiaomi released an update (MIUI V12.0.1.0 - R****M) which introduce Android 11.
My mod is still perfectly working with this update and Android 11 without any modifications !
So, you can still follow this tutorial to enhance your device audio quality
_xenoxis_ said:
... (deleted)
EDIT : i can't attach the file to my post, anyway i sent it to mediafire and there is the download link
Download the Audio Configuration files tuned for HI-RES
If you have any comments, any remarks or want help, do not hesitate to ask.
Click to expand...
Click to collapse
Your audio_policy_configuration.xml has '<globalConfiguration speaker_drc_enabled="true"/>', and this means DRC (Dynamic Range Control) has been enabled on your all audio outputs. This is the reason the THD+N of your device is larger than that of usual hifi devices. Try replace the true with false in your configuration.xml file.
If you like, see maximizing the audio quality of bluetooth.
zyhk said:
Your audio_policy_configuration.xml has '<globalConfiguration speaker_drc_enabled="true"/>', and this means DRC (Dynamic Range Control) has been enabled on your all audio outputs. This is the reason the THD+N of your device is larger than that of usual hifi devices. Try replace the true with false in your configuration.xml file.
If you like, see maximizing the audio quality of bluetooth.
Click to expand...
Click to collapse
Thanks for your reply, i tried on my device but i don't know if I can hear a difference between before and now or if is it a placebo effect.
Android's audio configuration are poorly documented, what does exactly DRC ?
Thanks again for this tips, it will be added in the mod
The sample rate of AudioManager always 192kHZ, not fit the song dynamically.
Even we ignored energy saving(96kHZ, 48kHZ, etc), but how to handle 44.1kHZ case?
SRC still exist in this case right?
RlTd said:
The sample rate of AudioManager always 192kHZ, not fit the song dynamically.
Even we ignored energy saving(96kHZ, 48kHZ, etc), but how to handle 44.1kHZ case?
SRC still exist in this case right?
Click to expand...
Click to collapse
Yes it doesn't fit the song dynamically (at least them which are lossy formatted songs), but this is the android default behaviour, and instead of putting anything in 48kHz (which can be bad for all musics sampled over 48kHz), with my mod it resampling everything at 192Khz, which can avoid frequencies repliement (cf Shannon-Nyquist's theorem) and can be benefit for the DAC's internal logic and post-treatments.
Anyway, some music players on Android define the "passthrough" flag on lossless formats which tell to Android to not upsample.
In 24bits float, upsampling is very precise, and there's be no distortions audible (if there distorsion, it will happen only close to the noise floor, which is inaudible anyway), so you can consider your 44.1Khz to be EXACTLY the same if they are upsampling to 192Khz.
If it was 16bits, I will not tell you the same, in 16bits, the noise floor is at 96Khz, and there's much more conversions errors in Integer than floats, and much more in 16bits than 24 bits, so in this case, it can be destructive.
_xenoxis_ said:
Yes it doesn't fit the song dynamically (at least them which are lossy formatted songs), but this is the android default behaviour, and instead of putting anything in 48kHz (which can be bad for all musics sampled over 48kHz), with my mod it resampling everything at 192Khz, which can avoid frequencies repliement (cf Shannon-Nyquist's theorem) and can be benefit for the DAC's internal logic and post-treatments.
Anyway, some music players on Android define the "passthrough" flag on lossless formats which tell to Android to not upsample.
In 24bits float, upsampling is very precise, and there's be no distortions audible (if there distorsion, it will happen only close to the noise floor, which is inaudible anyway), so you can consider your 44.1Khz to be EXACTLY the same if they are upsampling to 192Khz.
If it was 16bits, I will not tell you the same, in 16bits, the noise floor is at 96Khz, and there's much more conversions errors in Integer than floats, and much more in 16bits than 24 bits, so in this case, it can be destructive.
Click to expand...
Click to collapse
Thanks!
Actually I am using Apple Music beta version which supporting lossless(even hi-res) resource. What can I do to "passthrough" upsample of Android? I saw a module called AINUR NARSIL in Magisk, is that work?
Two most common lossless formats in Apple Music are 16bit_44.1kHZ and 24bit_96kHZ. As you said, 16bit may cause serious problems? BTW, what's the difference between AUDIO_FORMAT_PCM_24_BIT_PACKED and AUDIO_FORMAT_PCM_24_BIT?
If 192kHZ works fine, how about 384?
RlTd said:
Thanks!
Actually I am using Apple Music beta version which supporting hi-res resource. What can I do to "passthrough" upsample of Android? I saw a module called AINUR NARSIL in Magisk, is that work?
Click to expand...
Click to collapse
You can't force to use the passthrough flag, it only depend on the music player implementation, how it use the Android's Audio layer. Apple Music can decode hi-res resources, but it not guaranteed that it use the passthrough flag behind. Anyway with my mod, even it doesn't use the passthrought flag, it will be upscaled to 192Khz which is sufficient for every hi-res listening.
Remember that the passthrough flag only tell to the Android Audio layer to not resampling the audio, which can be bad with music with a low sampling rate (as 44.1Khz or even 48Khz), cause there's no margin for audio processing in the DAC or high frequencies already in the audio source file.
I don't know about if the AINUR NARSIL mod can force the passthrough, the better is to test it yourself i would say
RlTd said:
Two most common lossless formats in Apple Music are 16bit_44.1kHZ and 24bit_96kHZ. As you said, 16bit may cause serious problems? BTW, what's the difference between AUDIO_FORMAT_PCM_24_BIT_PACKED and AUDIO_FORMAT_PCM_24_BIT?
Click to expand...
Click to collapse
Yes 16 bits may cause interpolations errors only if the destination rate isn't a multiple of the original rate and only if Android make the upsampling by maintaining the output level if the destination sampling rate is a multiple of the original one. This is a bit technical, and I don't know what Android decide and do, but in the worst case, yes, 16 bits integer sound makes more interpolation errors cause 16 bits is less precise than 24 bits float and makes more rounding errors.
For your last question, AUDIO_FORMAT_PCM_24BIT doesn't exist.
According to https://android.googlesource.com/platform/hardware/interfaces/+/master/audio/common/4.0/types.hal :
Code:
/* Subformats */
PCM_SUB_16_BIT = 0x1, // PCM signed 16 bits
PCM_SUB_8_BIT = 0x2, // PCM unsigned 8 bits
PCM_SUB_32_BIT = 0x3, // PCM signed .31 fixed point
PCM_SUB_8_24_BIT = 0x4, // PCM signed 8.23 fixed point
PCM_SUB_FLOAT = 0x5, // PCM single-precision float pt
PCM_SUB_24_BIT_PACKED = 0x6, // PCM signed .23 fix pt (3 bytes)
So there's just two different version of representing 24bits data.
You should take a look here, you'll probably learn some tips on how Android handle audio data
_xenoxis_ said:
You can't force to use the passthrough flag, it only depend on the music player implementation, how it use the Android's Audio layer. Apple Music can decode hi-res resources, but it not guaranteed that it use the passthrough flag behind. Anyway with my mod, even it doesn't use the passthrought flag, it will be upscaled to 192Khz which is sufficient for every hi-res listening.
Remember that the passthrough flag only tell to the Android Audio layer to not resampling the audio, which can be bad with music with a low sampling rate (as 44.1Khz or even 48Khz), cause there's no margin for audio processing in the DAC or high frequencies already in the audio source file.
I don't know about if the AINUR NARSIL mod can force the passthrough, the better is to test it yourself i would say
Yes 16 bits may cause interpolations errors only if the destination rate isn't a multiple of the original rate and only if Android make the upsampling by maintaining the output level if the destination sampling rate is a multiple of the original one. This is a bit technical, and I don't know what Android decide and do, but in the worst case, yes, 16 bits integer sound makes more interpolation errors cause 16 bits is less precise than 24 bits float and makes more rounding errors.
For your last question, AUDIO_FORMAT_PCM_24BIT doesn't exist.
According to https://android.googlesource.com/platform/hardware/interfaces/+/master/audio/common/4.0/types.hal :
Code:
/* Subformats */
PCM_SUB_16_BIT = 0x1, // PCM signed 16 bits
PCM_SUB_8_BIT = 0x2, // PCM unsigned 8 bits
PCM_SUB_32_BIT = 0x3, // PCM signed .31 fixed point
PCM_SUB_8_24_BIT = 0x4, // PCM signed 8.23 fixed point
PCM_SUB_FLOAT = 0x5, // PCM single-precision float pt
PCM_SUB_24_BIT_PACKED = 0x6, // PCM signed .23 fix pt (3 bytes)
So there's just two different version of representing 24bits data.
Click to expand...
Click to collapse
Much to learn.
One more question: your Sample Rate Checker showed that "LINE_ANALOG Encodings" is AUDIO_FORMAT_PCM_FLOAT. I got same result with my earphone. Our related setting should be AUDIO_FORMAT_PCM_24_BIT_PACKED. Thus i am confusing about that. Do you know why?
Here is my log and its screenshots. Some FLOAT words also appeared in it. Looks like Qualcomm handle audio by FLOAT format. I don't know if they have similar reason.
RlTd said:
One more question: your Sample Rate Checker showed that "LINE_ANALOG Encodings" is AUDIO_FORMAT_PCM_FLOAT. I got same result with my earphone. Our related setting should be AUDIO_FORMAT_PCM_24_BIT_PACKED. Thus i am confusing about that. Do you know why?
Here is my log and its screenshots. Some FLOAT words also appeared in it. Looks like Qualcomm handle audio by FLOAT format. I don't know if they have similar reason.
Click to expand...
Click to collapse
AUDIO_FORMAT_PCM_24_BIT_PACKED is the sub-format which is the float format in Android (as showed in my last reply), it contain only factional part and no integer part.
AUDIO_FORMAT_PCM_FLOAT is just a short alias which refer to it.
So, AUDIO_FORMAT_PCM_24_BIT_PACKED is strictly equal to AUDIO_FORMAT_PCM_FLOAT.
Apparently on your device, is it already setup to handle hifi audio in the record processing as well as the output, everything is in 24bits (float) @ 384KHz, which is very nice !
Which device is it ?
_xenoxis_ said:
AUDIO_FORMAT_PCM_24_BIT_PACKED is the sub-format which is the float format in Android (as showed in my last reply), it contain only factional part and no integer part.
AUDIO_FORMAT_PCM_FLOAT is just a short alias which refer to it.
So, AUDIO_FORMAT_PCM_24_BIT_PACKED is strictly equal to AUDIO_FORMAT_PCM_FLOAT.
Apparently on your device, is it already setup to handle hifi audio in the record processing as well as the output, everything is in 24bits (float) @ 384KHz, which is very nice !
Which device is it ?
Click to expand...
Click to collapse
Xiaomi mix2s with snapdragon 845.
Its integrated audio codec DSP is WCD9341, which has better dynamic range than WCD9385(snapdragon 888).
WCD9341 | Qualcomm
www.qualcomm.com
I carry it everyday as a "hi-fi" player.
RlTd said:
Xiaomi mix2s with snapdragon 845.
Its integrated audio codec DSP is WCD9341, which has better dynamic range than WCD9385(snapdragon 888).
WCD9341 | Qualcomm
www.qualcomm.com
I carry it everyday as a "hi-fi" player.
Click to expand...
Click to collapse
I can see the THD+N (Total Harmonics Distortions + Noise) is at -109dB for the WCD9341 and at -108 for the WWCD9385, which is exactly the same (you can't hear the difference, i dare anyone to tell me otherwise).
Don't refer to the "Playback Dynamic Range", which don't represent what is it outputted (you have to add the noise and the harmonics distortions).
You're very right to use it as a everyday hifi player ! I'm very surprise that Xiaomi has think to set the DAC in a hi-res mode by default. I'm wondering why they haven't do the same for their new devices .
_xenoxis_ said:
You're very right to use it as a everyday hifi player ! I'm very surprise that Xiaomi has think to set the DAC in a hi-res mode by default. I'm wondering why they haven't do the same for their new devices .
Click to expand...
Click to collapse
Actually I also changed configs as your mod and turn more items else to 24bit/384kHZ to ensure hi-res works. However, i don't know which features are essential for me.
RlTd said:
Actually I also changed configs as your mod and turn more items else to 24bit/384kHZ to ensure hi-res works. However, i don't know which features are essential for me.
View attachment 5361457
View attachment 5361459
View attachment 5361461
View attachment 5361463
Click to expand...
Click to collapse
"hifi_playback" is just an unused output which isn't routed to anything, so don't mind about it.
About your sampling rate change to 384kHz, this will not gonna set it to 384Khz cause you don't change the file "audio_io_policy.conf" where is the i/o configuration (currently, your configuration can cause some volume saturation as it done the first time I tried my mod on my device).
You need to set 384KHz as well in this file.
Moreover, is it useless to set the USB output over to 192Khz, I don't know a device in USB which can handle 384KHz audio on a USB connection.
However, I don't think there's a reel benefit to set the DAC to 384KHz, I mean the maximum sampling rate in PCM hi-res file is 192Khz (still rare actually) and I never seen anything beyond this value. Typically a hi-res file is in [email protected]
So what i'm trying to say, is that a change from [email protected] to [email protected] is beneficial, for many reasons (16-->24 bits, integer mode to float, increasing sampling rate), but passing from 192KHz to 384KHz is, in my opinion, completely useless.
Moreover, a value that high can increase the risk of causing some jitter (which normally can't happen even at 384Khz, but theoretically the risk increase).
And finally, you'll consume more power for nothing.
_xenoxis_ said:
"hifi_playback" is just an unused output which isn't routed to anything, so don't mind about it.
About your sampling rate change to 384kHz, this will not gonna set it to 384Khz cause you don't change the file "audio_io_policy.conf" where is the i/o configuration (currently, your configuration can cause some volume saturation as it done the first time I tried my mod on my device).
You need to set 384KHz as well in this file.
Moreover, is it useless to set the USB output over to 192Khz, I don't know a device in USB which can handle 384KHz audio on a USB connection.
However, I don't think there's a reel benefit to set the DAC to 384KHz, I mean the maximum sampling rate in PCM hi-res file is 192Khz (still rare actually) and I never seen anything beyond this value. Typically a hi-res file is in [email protected]
So what i'm trying to say, is that a change from [email protected] to [email protected] is beneficial, for many reasons (16-->24 bits, integer mode to float, increasing sampling rate), but passing from 192KHz to 384KHz is, in my opinion, completely useless.
Moreover, a value that high can increase the risk of causing some jitter (which normally can't happen even at 384Khz, but theoretically the risk increase).
And finally, you'll consume more power for nothing.
Click to expand...
Click to collapse
My system is MIUI11. A file called "audio_output_policy.conf" in same place which has the same content as a part of your audio_io_policy.conf. I've edited it and other file called "audio_policy.xml" in case.
Jitter looks getting higher in log but I don't know if I can hear it apparently.
Even I removed all energy-cost-optimizing-strategy on my music app to enhance stability of performance with 384kHZ. The battery cost is still acceptable.
Indeed, it makes me feel little bit weird when adopting 384kHz. All I do this is considering SRC from 44.1kHZ. Higher sampling may cause more reasonable curve in analog signal. However, it depends on algorithm and may cause other problems like harmonic wave and jitter. So it's an experiment and a trade-off. I will go back to 192kHZ if got nothing on 44.1kHZ files after comparing.
_xenoxis_ said:
"hifi_playback" is just an unused output which isn't routed to anything, so don't mind about it.
About your sampling rate change to 384kHz, this will not gonna set it to 384Khz cause you don't change the file "audio_io_policy.conf" where is the i/o configuration (currently, your configuration can cause some volume saturation as it done the first time I tried my mod on my device).
You need to set 384KHz as well in this file.
Moreover, is it useless to set the USB output over to 192Khz, I don't know a device in USB which can handle 384KHz audio on a USB connection.
Click to expand...
Click to collapse
I'm making a USB Sample Rate Changer script like bluetooth LDAC and usb-samplerate-unlocker (up to 386kHz and even 768kHz). If you like, see my github USB Sample Rate Changer and usb-samplerate-unlocker.
Update 08/07/2021 :
Hello guys, i have made a magisk module with this mod, it's currently on submission stage and it will be, normally, fully available in the magisk module repository (the "market").
With this magisk module, the mod will be systemless and will no require tricks to hard-modifying files on the device !
I'll keep you informed about this !
Great work.
I need to do the same in my K20 pro (Raphaelin), for the apple music lossless to use the inbuilt hifi dac