I'm sure you noticed that when you record a 720p/1080p video with a smartphone, the bitrate will be pretty high, in the 10-15Mbps area.
This is not really necessary if you watch the videos just on your smartphone or on a limited size LCD TV, and you can just recompress it using x264 codec at about 2Mbps without severe quality loss (unless it's a sport video).
However you'll notice severe audio video out-of-sync issues if you compress both audio and video tracks and DON'T CHOOSE MP4 (which is the default container for the videos recorded by the smartphone) as default container for your x264 video.
Furthermore, if you want to compress and then JOIN different videos, you have to compress them one by one and THEN join them, otherwise you'll notice glitches in the playback.
I tried with mkv and avi but I kept having sync issues, so I thought that it was worth to share this tip.
SUPER @ video conversion program
Have you tried a video conversion program called SUPER @? Here's its link:
http://www.erightsoft.com/SUPER.html
The program can be pretty intensive in terms of memory used but it usually does a great job for me and bitrates can be chosen for just any vid type you might want to save to. Usually, I turn off my internet connection prior to executing it (so it can't do an update check) and run it by itself.
Yep, I guess it's something similar to Wondershare Video Converter Ultimate, it's just that I prefer more control over encoding parameters (so I tend to use programs such as Avidemux)
flapane said:
Yep, I guess it's something similar to Wondershare Video Converter Ultimate, it's just that I prefer more control over encoding parameters (so I tend to use programs such as Avidemux)
Click to expand...
Click to collapse
You've probably already thought of this but you can load your video in virtualdubmod and have it change framerate so video and audio match perfectly.
No re encoding needed and even on large files it takes less than a minute or two.
If you find virtualdubmod won't recognise the video you can download a suitable vfw codec and it should then.
Dave
( http://www.google.com/producer/editions/CAownKXmAQ/bigfatuniverse )
Sent from my LG P920 using Tapatalk 2
The problem is that vdubmod won't help, because framerate is not constant and it varies from some 19 to 30fps, at least on Vibrant.
In a lot of cases the fps number gets lost during encoding (and you'll obtain a video which has a constant framerate of 29.97fps), because softwares such as Avidemux doesn't have an option to leave the FPS untouched (or at least it seems that the fps number gets lost if you want to use MKV as container).
flapane said:
The problem is that vdubmod won't help, because framerate is not constant and it varies from some 19 to 30fps, at least on Vibrant.
In a lot of cases the fps number gets lost during encoding (and you'll obtain a video which has a constant framerate of 29.97fps), because softwares such as Avidemux doesn't have an option to leave the FPS untouched (or at least it seems that the fps number gets lost if you want to use MKV as container).
Click to expand...
Click to collapse
I've used it in similar situations so it might be worth a try as it doesn't need a constant framerate, it looks at the audio length then adjusts video framerate to match.
If it is just a problem created while actually recording, ie if the video itself records at varying framerates it would suggest that it can't write to storage quick enough and is dropping frames.
In that case you would need to record in lower resolution or perhaps find a replacement camera application and see if that could fix your problem as sometimes default apps are not all that good.
It also makes a difference if you can close un needed background apps to free ram if low on memory. That can cause frames to drop as well.
Dave
( http://www.google.com/producer/editions/CAownKXmAQ/bigfatuniverse )
Sent from my LG P920 using Tapatalk 2
Actually it seems that the framerate is lower in case of dark scenes, which seems to be a behaviour found on other phones. I'm writing on the internal storage and I always kill everything before taking a video, so I gotta try another Camera app and see if anything changes.
I'll also take a look at that interesting vdubmod feature, I didn't know it.
Thanks.
flapane said:
Actually it seems that the framerate is lower in case of dark scenes, which seems to be a behaviour found on other phones. I'm writing on the internal storage and I always kill everything before taking a video, so I gotta try another Camera app and see if anything changes.
I'll also take a look at that interesting vdubmod feature, I didn't know it.
Thanks.
Click to expand...
Click to collapse
Is there a setting where you can change encoding parameters of your x264 on your phone?
On a pc the codec has a feature that can compress more data per frame in darker areas, on a phone I don't know if that is active or not but might be worth checking. Sorry I couldn't help more but hope you find a solution.
Dave
( http://www.google.com/producer/editions/CAownKXmAQ/bigfatuniverse )
Sent from my LG P920 using Tapatalk 2
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