And so would I. The only thing LG did right, was pick ESS hardware.
Audio is very clearly not the priority with Android devices, even the V30 (despite it's marketing - and shockingly good sound if SRC can be mitigated). Audio is the priority for ESS tech, who is solely responsible for the headphone jack's performance. Of course the DAC chip supports 44/16. Do you really think ESS would purposely omit that from the list of supported sample rate / word lengths? It would be like making a TV that didn't support 1080p 16:9 aspect ratio.
“The only thing LG did right, was pick ESS hardware”
I understand the annoyance that folks have about the sample rate. Seems a pretty basic mistake. Having said that it might be a bit harsh to say that is the ONLY thing that LG did right. In a day and age when more and more are abandoning the audio jack, they tenaciously hung on. They chose a relatively premium implementation as opposed to just let the internal SOC do the work. I think that they are serving the audio community better than most other cellular phone vendors. I for one am ok with UAPP as a workaround for now, all things considered.
But, yeah, seems like a boneheaded mistake when everything else is going the right way.
In a day and age when more and more are abandoning the audio jack, they tenaciously hung on. They chose a relatively premium implementation as opposed to just let the internal SOC do the work.
Right now I carry a IPhone XS Max as a smartphone and SIM FREE V30 as dedicated DAP for its LDAC, 3.5mm jack for HiRes Audio and MQA Tidal.
I couldn’t use the iPhone as DAP primarily because it lacks LDAC and MQA Tidal.
And I wouldn’t use the V30 or any other android as my smartphone as I value privacy and security.
I've done this exact same thing .. my Xs MAX is my phone and the LG G6 is my DAC... I don't even have a sim in it, as it's basically a DAP for when I'm in Wifi
Created an account just to thank the OP. I recently bought a used V30 with the goal of having good sound quality on my new (to me) phone. My previous phone was a OnePlus One, which has fantastic sound quality - it's mostly broken as a smartphone now but I still use it as a source for my integrated amp. So when I got the V30 and connected my Etymotic ER3SE, which are pretty sensitive, I got very disappointed with all the artifacts and distortions at low volume. I have now installed Neutron and adjusted the settings as described in the post and I am again a happy listener!
Thanks again to OP and the developers of Neutron (and any other apps that work well with the V30 constraints).
Created an account just to thank the OP. I recently bought a used V30 with the goal of having good sound quality on my new (to me) phone. My previous phone was a OnePlus One, which has fantastic sound quality - it's mostly broken as a smartphone now but I still use it as a source for my integrated amp. So when I got the V30 and connected my Etymotic ER3SE, which are pretty sensitive, I got very disappointed with all the artifacts and distortions at low volume. I have now installed Neutron and adjusted the settings as described in the post and I am again a happy listener!
Thanks again to OP and the developers of Neutron (and any other apps that work well with the V30 constraints).
Nice post. I think you are right that the ESS 9218P does support 16/44 (as also hinted in @csglinux' recent post as well). I spent some time with a friend last fall who designs extremely high-end equipment, and he had tested ESS 9028 for their DAC (before settling on Cirrus Logic/Crystal instead). No doubt he would have mentioned such an issue, as much of their focus is to achieve the best possible Redbook playback.
But it won't matter if LG's driver doesn't support it, since that driver is our path to the DAC hardware. It is noteworthy that Davy (UAPP's developer) chose as workaround to convert 16/44 to 24/44. I have to presume his first choice would have been to deliver 16/44 directly to the DAC if at all possible.
I suppose it is possible that the driver DOES support 16/44, but for whatever reason LG chose to not expose that support. OR they chose to configure the policies used by audio_flinger (the module that directs audio from input sources to output devices) to not support it -- which we CAN change on a rooted phone if we knew how. (I have a feeling that's what csglinux is busy working on these days.)
But that leads to the question of why LG chose to do this? I do NOT believe that they were simply too stupid or they didn't care about audio quality. If that were the case, they wouldn't have given us the ESS DAC in the first place. My guess is that something drove them to this decision back in the days of V10 or V20, when earlier Android versions were more simplistic about audio support.
I have a feeling that this will change when we get the Android Pie update. With the audio improvements in Android 8 and 9, AND LG maybe taking inspiration from UAPP and Neutron, I think they may just get it right this time.
Yes,
I have some experience with customizing the sound config in LG V10 and Lenovo Vibe X3 when I can get the root access.
For me, the software of Lenovo is more audio playback orientation than LG - at least, with PCM playback they can support 16/192 (not 24 bits) - and it's better than LG because without rooting you can not do anything to change the default playback 14/48.
For me-PCM playback is more bit-perfect because it uses alsa to send pcm signal directly to DAC bypass any audioflinger - With alsaplayer(you can check it on XDA) I can play 24/192 flac file - ofcourse this player is not for everyone.
I don't now how UAPP, Neutron do play Hi-res file - because without modifying config file, they can not play these file and give correct output( I mean in PCM Mode). At least Poweramp can play 16/192 for Lenovo's phone.
If these app play in compress-offload mode - the sittuation is the same,they may say they give Hi-res output but I don't think so, you can easyly check it with alsa command.
I know why LG set 16.48 in default for everything - because this is not a DAP, the Android have to manage many kind of sound, not only music - the phone will lag/and eat power if they will treat these sound as 24/192. This is why Onkyo Grandbeat have to separate the board for difference job.
There is hardly a more trivial and transparent process than padding a 16 bit audio sample into a 24-bit pipeline. It's a non-issue, really.
As to why LG is stuck with 16-48K and don't take advantage of the capabilities of the ESS chip-set?
Consider that (at least) two entirely different teams worked on the audio development and as sometimes happens in large corporations, absurd lapses in communications scuttle great intentions.
I'm speculating, of course, and it is at least as plausible anything offered in the way of conspiracy, etc.
Yes,
I have some experience with customizing the sound config in LG V10 and Lenovo Vibe X3 when I can get the root access.
For me, the software of Lenovo is more audio playback orientation than LG - at least, with PCM playback they can support 16/192 (not 24 bits) - and it's better than LG because without rooting you can not do anything to change the default playback 14/48.
For me-PCM playback is more bit-perfect because it uses alsa to send pcm signal directly to DAC bypass any audioflinger - With alsaplayer(you can check it on XDA) I can play 24/192 flac file - ofcourse this player is not for everyone.
I don't now how UAPP, Neutron do play Hi-res file - because without modifying config file, they can not play these file and give correct output( I mean in PCM Mode). At least Poweramp can play 16/192 for Lenovo's phone.
If these app play in compress-offload mode - the sittuation is the same,they may say they give Hi-res output but I don't think so, you can easyly check it with alsa command.
I know why LG set 16.48 in default for everything - because this is not a DAP, the Android have to manage many kind of sound, not only music - the phone will lag/and eat power if they will treat these sound as 24/192. This is why Onkyo Grandbeat have to separate the board for difference job.
Fascinating post - thanks for sharing! Do you still have access to an LG phone? If so, what's your success rate at bypassing the Android mixer? I've been trying a number of things on my rooted V30, but with no luck. I did find one post on the V20 thread that looked optimistic:
However, I've tried this on the V30 and it doesn't work. The V30 Oreo /system/build.prop does not contain this line:
audio.offload.pcm.16bit.enable=false
But it does contain this line:
vendor.audio.offload.pcm.16bit.enable=false
Changing the above to "true", and/or adding "audio.offload.pcm.16bit.enable=true" has no effect on the V30.
The closest I've gotten to something interesting was to replace the AUDIO_FORMAT_PCM_16_BIT flags in audio_policy.conf and audio_policy_configuration.xml in /etc, /vendor/etc and /vendor/etc/audio with
AUDIO_FORMAT_PCM_24_BIT_PACKED. This results in audio_flinger reporting 44 kHz/24 bit, but it still goes through the mixer. (I still hear the resampling artifacts and audio_flinger still reports "mixer" on the output thread). I've never heard a V20, so I'm not 100% sure the fix in the above link actually worked, or just tricked audio_flinger. The internet is rife with people hearing "night and day" differences over tweaks that have demonstrably no effect on the audio However, it does look interesting that the output thread reports "DIRECT". I've not been able to get the V30 to do that.
So the bottom line is, we'd all love to hear from you if you have any thoughts or suggestions on a system-wide fix for the V30 re-sampling issue...?
P.S. Neutron and UAPP avoid this problem by calling the separate AudioTrack API. This results in direct or direct_pcm playback, sending the audio buffer straight to the DAC and by-passing the mixer. It works. Bit-perfect (you're only padding zeros, as @zenmastering points out) - and as a result of by-passing the mixer, there's no resampling. But it's not a global panacea, because we (as users) can't add AudioTrack calls to 3rd party apps. It's the streaming apps that are the remaining issue for us, e.g., we can't play offline 44 kHz PCM via the Tidal app without Android upsampling back to 48 kHz. TBH, I'm not sure what nasty side-effects there'd be if we could also persuade all 44 kHz PCM to bypass the mixer. I suspect there'd be none. The frustrating part of all this is how long this has been an issue. I've tried to reach support techs at LG and Tidal, but have never been able to find anyone who could even understand or acknowledge there's an issue. I have a depressing little sportsmans bet on at the moment with @Dannemand that the V50 is going to have the exact same problem.
Yes,
I have some experience with customizing the sound config in LG V10 and Lenovo Vibe X3 when I can get the root access.
For me, the software of Lenovo is more audio playback orientation than LG - at least, with PCM playback they can support 16/192 (not 24 bits) - and it's better than LG because without rooting you can not do anything to change the default playback 14/48.
For me-PCM playback is more bit-perfect because it uses alsa to send pcm signal directly to DAC bypass any audioflinger - With alsaplayer(you can check it on XDA) I can play 24/192 flac file - ofcourse this player is not for everyone.
I don't now how UAPP, Neutron do play Hi-res file - because without modifying config file, they can not play these file and give correct output( I mean in PCM Mode). At least Poweramp can play 16/192 for Lenovo's phone.
If these app play in compress-offload mode - the sittuation is the same,they may say they give Hi-res output but I don't think so, you can easyly check it with alsa command.
I know why LG set 16.48 in default for everything - because this is not a DAP, the Android have to manage many kind of sound, not only music - the phone will lag/and eat power if they will treat these sound as 24/192. This is why Onkyo Grandbeat have to separate the board for difference job.
I do want to make sure we keep two issues separate: (1) Downsampling of HighRes music to 48kHz and (2) upsampling of Redbook 16/44 to 48kHz.
1) V30 DOES NOT have a problem with downsampling HighRes music. I have been harping on this in several different threads because I keep seeing posts that claim it does. Apparently many Android devices DO play HighRes music through the Android Mixer, causing it to be downsampled, particularly when playing through USB. But when QuadDAC is enabled on V30, HighRes music (or anything 24-bit) will be routed by audioflinger through the Direct path, as long as the bit-depth and sample rate are supported by the ESS DAC.
And we do not even need UAPP or Neutron: LG Music app will do it too. And so will a dumb app such as Google Play Music (up to 192kHz). I give you the following audioflinger dumps as evidence. They look exactly the same as if the files had played through UAPP:
Output thread 0xed9ad000, name AudioOut_6D, tid 4751, type 1 (DIRECT):
I/O handle: 109
Standby: no
Sample rate: 44100 Hz
HAL frame count: 1792
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 10752 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
Processing frame size: 6 bytes
Pending config events: none
Output device: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
Input device: 0 (AUDIO_DEVICE_NONE)
Audio source: 0 (default)
Normal frame count: 1792
Last write occurred (msecs): 37
Total writes: 1026
Delayed writes: 0
Blocked in write: yes
Suspend count: 0
Sink buffer : 0xed9c1000
Mixer buffer: 0xed9df000
Effect buffer: 0xed916000
Fast track availMask=0xfe
Standby delay ns=1000000000
AudioStreamOut: 0xeff8e000 flags 0x1 (AUDIO_OUTPUT_FLAG_DIRECT)
Output thread 0xe4b41000, name AudioOut_17D, tid 6310, type 1 (DIRECT):
I/O handle: 381
Standby: no
Sample rate: 176400 Hz
HAL frame count: 7072
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 42432 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
Processing frame size: 6 bytes
Pending config events: none
Output device: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
Input device: 0 (AUDIO_DEVICE_NONE)
Audio source: 0 (default)
Normal frame count: 7072
Last write occurred (msecs): 32
Total writes: 143
Delayed writes: 0
Blocked in write: yes
Suspend count: 0
Sink buffer : 0xe3bf0000
Mixer buffer: 0xe2e34000
Effect buffer: 0xe41ed000
Fast track availMask=0xfe
Standby delay ns=1000000000
AudioStreamOut: 0xe77d9ee0 flags 0x1(AUDIO_OUTPUT_FLAG_DIRECT)
I do not for a second believe that Google Play Music (which is otherwise annoyingly dumb) has special support for our QuadDAC. It (or audioflinger) simply queries the audio formats supported by the output device (the so-called "sink") and uses the Direct route when it matches the source.
Another related, and oft repeated myth around these parts, is that the Tidal app re-samples Master/MQA tracks, or it doesn't do the MQA unfolding correctly, or (at very best) it only does 2x unfolding in software. The truth is that the Tidal app plays MQA exactly the same as UAPP: Using the Direct route, without molesting the stream, but adding the MQA flag (0x400001 vs 0x1) causing the mqadummy effect to kick in -- which presumably is what triggers full 4x hardware unfolding and rendering.
Notice how the audioflinger dumps looks exactly the same between Tidal app and UAPP when playing MQA:
Output thread 0xe4f31000, name AudioOut_8D, tid 13140, type 1 (DIRECT):
I/O handle: 141
Standby: no
Sample rate: 44100 Hz
HAL frame count: 1792
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 10752 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
Processing frame size: 6 bytes
Pending config events: none
Output device: 0x4 (AUDIO_DEVICE_OUT_WIRED_HEADSET)
Input device: 0 (AUDIO_DEVICE_NONE)
Audio source: 0 (default)
Normal frame count: 1792
Last write occurred (msecs): 5
Total writes: 119
Delayed writes: 0
Blocked in write: yes
Suspend count: 0
Sink buffer : 0xe7354000
Mixer buffer: 0xe6603000
Effect buffer: 0xe68e1800
Fast track availMask=0xfe
Standby delay ns=1000000000
AudioStreamOut: 0xe788e0c0 flags 0x400001 (AUDIO_OUTPUT_FLAG_DIRECT)
Output thread 0xe736d000, name AudioOut_65, tid 10565, type 1 (DIRECT):
I/O handle: 101
Standby: no
Sample rate: 44100 Hz
HAL frame count: 1792
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 10752 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
Processing frame size: 6 bytes
Pending config events: none
Output device: 0x4 (AUDIO_DEVICE_OUT_WIRED_HEADSET)
Input device: 0 (AUDIO_DEVICE_NONE)
Audio source: 0 (default)
Normal frame count: 1792
Last write occurred (msecs): 20
Total writes: 48
Delayed writes: 0
Blocked in write: yes
Suspend count: 0
Sink buffer : 0xe735d000
Mixer buffer: 0xe6ef4000
Effect buffer: 0xe6e54000
Fast track availMask=0xfe
Standby delay ns=1000000000
AudioStreamOut: 0xe792b0c0 flags 0x400001 (AUDIO_OUTPUT_FLAG_DIRECT)
2) V30 DOES have a problem with upsampling Redbook 16/44 music. And of course that's what we've been discussing in great length, and which @csglinux has been trying to solve by editing the audio_policy_configuration.xml file used by audioflinger to match sources (music streams) to sinks (output devices).
On this issue, I have been the grinch, posting repeatedly how I doubt changing Android 's default sample rate from 48hKz to 44.1kHz (as suggested on the Reddit spotted by @VI001101106 in this post) will overcome the problem. I similarly doubt that changing the policies alone can do it (although I am more optimistic about that).
As elaborated in my posts here and here, my reasoning is that as long LG's audio driver does not support 16/44, there is no way we can force it to accept such a data stream, even if the ESS DAC itself accepts 16/44. That is why UAPP converts 16/44 to 24/44, which the driver DOES support, and which plays perfectly through the Direct route.
I think the only realistic solution is to modify audioflinger (or AndroidMixer which I believe is part of it) to actively convert 16/44 to 24/44, the same as UAPP does. The IDEAL solution would be to change LG's audio driver to accept 16/44 directly: We all seem to trust that the ESS DAC can play it natively, and if not, the driver is the one that should convert it to 24/44. But source code for vendor provided hardware drivers are usually not available, so that solution is not realistic.
And now, this is where I become the optimist: Yes, I DID say I had a feeling it might be better in Pie. And csglinux DID offer a bet that it wouldn't (although I never accepted the bet). I'll give it a 50/50 chance, so not a bad bet considering the reward/risk: We'd be losing nothing if it ISN'T solved, but we'd have a perfect music source if it IS. So I remain cautiously optimistic about Pie
That would be great if you can test it as soon as you get Pie.
You need ADB (Android Device Bridge) working on a computer, and enable USB Debugging under Developer Options on the phone. Once you have that, follow the steps on the bottom of this UAPP support page, under the headline Verifying the correct working of the driver. Now play a 16/44 file using LG Music, Tidal, Google Play Music or other apps that we know currently cause upsampling. Then enter the dumpsys command.
Instead of entering adb shell and dumpsys as a separate commands (like suggested on that UAPP page), I suggest something like:
This will capture the output in the log file you specify (on the computer, in the ADB folder where you ran the command). Then look for the last Output thread section and compare it to my spoilers above.
That would be great if you can test it as soon as you get Pie.
You need ADB (Android Device Bridge) working on a computer, and enable USB Debugging under Developer Options on the phone. Once you have that, follow the steps on the bottom of this UAPP support page, under the headline Verifying the correct working of the driver. Now play a 16/44 file using LG Music, Tidal, Google Play Music or other apps that we know currently cause upsampling. Then enter the dumpsys command.
Instead of entering adb shell and dumpsys as a separate commands (like suggested on that UAPP page), I suggest something like:
This will capture the output in the log file you specify (on the computer, in the ADB folder where you ran the command). Then look for the last Output thread section and compare it to my spoilers above.
So I tried it with the G7 now and the sample rate was obviously 48kHz. But so was the Pixel 3 (playing Tidal HiFi). Now, it did play thru the speaker since I can't have the dongle plugged in and also have it connected to my desktop.
Was this supposed to be fixed in Pie period or are you expecting LG specifically to fix this in their devices once they get updated?
So I tried it with the G7 now and the sample rate was obviously 48kHz. But so was the Pixel 3 (playing Tidal HiFi). Now, it did play thru the speaker since I can't have the dongle plugged in and also have it connected to my desktop.
Was this supposed to be fixed in Pie period or are you expecting LG specifically to fix this in their devices once they get updated?
You definitely want to test this with headphones plugged in, not through speakers. Otherwise the ESS DAC won't be active. But in any case would the sample rate be 48kHz when playing 16/44 (except through UAPP or Neutron) and it will say MIXER instead of DIRECT. Try playing a HiRes file and see what happens.
And I don't know that this will be addressed in Pie. I just naively choose to be optimistic about it. LG has already tweaked audioflinger and/or policies to ensure HiRes music plays correctly, not just from their own LG Music, but also from other apps. As I understand, that wasn't the case in V10 or V20 (though I could be wrong). I'm just thinking the reason they didn't also address 16/44 already is because they're saving it for Pie.
Edit: Oh, and good job getting that dumpsys working!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
However, it does look interesting that the output thread reports "DIRECT". I've not been able to get the V30 to do that.
