Avoiding Android Mixer/48Khz upsampling of 44.1/16 audio

Search This thread

TheDannemand

Senior Member
Feb 12, 2008
1,168
1,181
Is anybody aware of a system-wide solution to avoid the upsampling of 44.1KHz / 16-bit music to 48KHz?

With system-wide, I mean a solution that does not rely on certain player apps such as UAPP or Neutron, which we know can do it, but only when playing from inside that app. A solution which works with all (or most) audio sources and apps, modifying the default system behavior of upsampling 44/16 to 48KHz when playing to the Quad DAC.

Personally, I am looking for solutions to work with Tidal offline tracks. Others are looking for solutions to Qobuz, Spotify, Google Play Music or other apps.

Do some of the custom ROMs have fixes for this? Are there policy file or build.prop changes that are proven to fix it?

Googling and searching on XDA finds many references to Android's infamous 48KHz upsampling/re-sampling (SRC) but none that look to be actual, working solutions for our phones. I hope I am wrong and that there is a simple fix which I overlooked.


Background

The LG V series and G series (most models) are appreciated by audiophiles for their excellent ESS Sabre DAC (ES9218P, branded Quad DAC by LG). It can deliver amazing sound quality when paired with good headphones or IEMs (In-Ear-Monitors, earphones). (And no, that doesn't necessarily mean High-Impedance headphones/IEMs, but that's a whole other discussion.)

V30 in particular has gained a rather large following among audiophiles, many of whom congregate on head-fi.org, where you will find a huge V30 thread, a growing V40 thread and a dedicated V30 Music apps, tricks and tips thread.

When it comes to HiRes music (anything higher than 48KHz sample rate and anything 24-bit) most music apps play it correctly: Bit-perfect, without any processing or re-sampling, directly to the DAC -- exactly as audiophiles want it. A few apps are known to downsample HiRes music to Android's default sample rate of 48KHz, but those are the exception.

However 44.1KHz / 16-bit music is always routed through Android's Mixer, which upsamples it to 48Khz. This causes artifacts that are audible to good ears, particularly when played on sensitive IEMs. Since 44/16 includes anything CD quality (whether compressed or uncompressed) that means most music in the world gets molested before it reaches the DAC.

For whatever reason, LGs implementation of the ESS DAC throughout the V and G series have suffered from this inability to play 44/16 music without upsampling. It is the one thing that truly hampers their reputation among audiophiles (arguably even more so than the inability to select between gain modes, which is annoying, but not a deal breaker for most).

This can be verified by inspecting the Output Thread of audio_flinger dumps, showing whether an output stream is played through the DIRECT path (not the MIXER path) and with the offloadable flag (sent straight to the DAC for decoding and rendering). Of course it can also be verified by listening for those artifacts.

The last 1.5 years, audiophile V30 users have relied on UAPP or Neutron as music players because they are able to work around this upsampling. They do so by converting 44/16 format music to 44/24 on the fly, adding zero bits to convert 16-bit to 24-bit. Different from the 48KHz upsampling, this is a harmless conversion which doesn't affect audio quality. (Of course it's also much faster, requiring no interpolation.) And once music is in 44/24 format, it is no problem sending it directly to the DAC, as described above.

We recently confirmed that PowerAmp also is able to do this correctly now (which wasn't always the case). But only if you configure it to convert all music to 44/24, which obviously isn’t desirable for HiRes.

UAPP is my personal favorite, as it also supports streaming services Tidal, Qobuz and Google Play Music, in addition to network services and any PCM or DSD file you can throw at it. All of it pristinely bit-perfect. But it cannot support Tidal or Qobuz offline, which means when playing offline you are limited to HiRes music (only a small part of their catalog) unless you can tolerate the 48KHz upsampling of CD quality tracks in the Tidal/Qobuz apps.

Head-Fi titan @csglinux and I have set out looking for a solution to this, along with other interested head-fi members. csglinux has been testing various policy and build.prop edits (so far no cigar), while I have been digging through the ESS driver source code from the kernel (but I am not set up to actually build the kernel).

More background and discussion can be found in csglinux' V30 Music apps, tricks and tips thread on head-fi. I also recently had a brief (and more technical) discussion with @ctheanh about this over in the XDA V40 forum, starting here. Arguably those posts would be more suited here.

We have several ideas, but it is a steep hill to climb, as none of us are Android developers. But before posting pages of what we have already tried, or dozens of audio_flinger dumps from various setups, we wanted to throw the topic out there for input. Again, maybe there is already a solution we have overlooked.

Any input is much appreciated!

TL;DR
I personally recommend UAPP as the best $8 anybody can spend if they care about sound quality on their V30. This is not about avoiding that. But UAPP doesn't cover all scenarios, in particular offline Tidal and Qobuz.

That's why we're looking for a system-wide fix (mod or custom ROM) that avoids the upsampling.
 
Last edited:

Mrxyzl

Senior Member
May 1, 2015
893
490
Sony Xperia 1 IV
Is anybody aware of a system-wide solution to avoid the upsampling of 44.1KHz / 16-bit music to 48KHz?

With system-wide, I mean a solution that does not rely on certain player apps such as UAPP or Neutron, which we know can do it. A solution which works with all (or most) audio sources and apps, changing the default behavior of upsampling 44/16 to 48KHz (when playing to the Quad DAC).

Personally, I am looking for solutions to work with Tidal offline tracks. Others are looking for solutions to Qobuz, Spotify, Google Play Music or other apps.

Do some of the custom ROMs have fixes for this? Are there policy file or build.prop changes that are proven to fix it?

Googling and searching on XDA finds many references to Android's infamous 48KHz upsampling/re-sampling (SRC) but none that look to be actual, working solutions for our phones. I hope I am wrong and that there is a simple fix which I overlooked.


Background

The LG V series and G series (most models) are appreciated by audiophiles for their excellent ESS Sabre DAC (ES9218P, branded Quad DAC by LG). It can deliver amazing sound quality when paired with good headphones or IEMs (In-Ear-Monitors, earphones). (And no, that doesn't necessarily mean High-Impedance headphones/IEMs, but that's a whole other discussion.)

V30 in particular has gained a rather large following among audiophiles, many of whom congregate on head-fi.org, where you will find a huge V30 thread, a growing V40 thread and a dedicated V30 Music apps, tricks and tips thread.

When it comes to HiRes music (anything higher than 48KHz sample rate and anything 24-bit) most music apps play it correctly: Bit-perfect, without any processing or re-sampling, directly to the DAC -- exactly as audiophiles want it. A few apps are known to downsample HiRes music to Android's default sample rate of 48KHz, but those are the exception.

However 44.1KHz / 16-bit music is always routed through Android's Mixer, which upsamples it to 48Khz. This causes artifacts that are audible to good ears, particularly when played on sensitive IEMs. Since 44/16 includes anything CD quality (whether compressed or uncompressed) that means most music in the world gets molested before it reaches the DAC.

For whatever reason, LGs implementation of the ESS DAC throughout the V and G series have suffered from this inability to play 44/16 music without upsampling. It is the one thing that truly hampers their reputation among audiophiles (arguably even more so than the inability to select between gain modes, which is annoying, but not a deal breaker for most).

This can be verified by inspecting the Output Thread of audio_flinger dumps, showing whether an output stream is played through the DIRECT path (not the MIXER path) and with the offloadable flag (sent straight to the DAC for decoding and rendering). Of course it can also be verified by listening for those artifacts.

The last 1.5 years, audiophile V30 users have relied on UAPP or Neutron as music players because they are able to work around this upsampling. They do so by converting 44/16 format music to 44/24 on the fly, adding zero bits to convert 16-bit to 24-bit. Different from the 48KHz upsampling, this is a harmless conversion which doesn't affect audio quality. (Of course it's also much faster, requiring no interpolation.) And once music is in 44/24 format, it is no problem sending it directly to the DAC, as described above.

We recently confirmed that PowerAmp also is able to do this correctly now (which wasn't always the case). But only if you configure it to convert all music to 44/24, which obviously isn’t desirable for HiRes.

UAPP is my personal favorite, as it also supports streaming services Tidal, Qobuz and Google Play Music, in addition to network services and any HiRes PCM or DSD file you can throw at it. All of it pristinely bit-perfect. But it cannot support Tidal or Qobuz offline, which means when playing offline you are limited to HiRes music (only a small part of their catalog) unless you can tolerate the 48KHz upsampling of CD quality tracks in the Tidal/Qobuz apps.

Head-Fi titan @csglinux and I have set out looking for a solution to this, along with other interested head-fi members. csglinux has been testing various policy and build.prop edits (so far no cigar), while I have been digging through the ESS driver source code from the kernel (but I am not set up to actually build the kernel).

More background and discussion can be found in csglinux' V30 Music apps, tricks and tips thread on head-fi. I also recently had a brief (and more technical) discussion with @ctheanh about this over in the XDA V40 forum, starting here. Arguably those posts would be more suited here.

We have several ideas, but it is a steep hill to climb, as none of us are Android developers. But before posting pages of what we have already tried, or dozens of audio_flinger dumps from various setups, we wanted to throw the topic out there for input. Again, maybe there is already a solution we have overlooked.

Any input is much appreciated!

Erm i suggest bit perfect mode on USB audio player pro
 

TheDannemand

Senior Member
Feb 12, 2008
1,168
1,181
Erm i suggest bit perfect mode on USB audio player pro

Thank you. Again, I already use that, and have for the last 1.5 years. But UAPP doesn't cover all scenarios, in particular offline Tidal and Qobuz, nor Spotify and other popular streaming services.

That's why I'm asking if anybody knows of a system-wide fix (mod or custom ROM) that avoids the upsampling.

I seem to recall that you did some work into this in a custom ROM, right?

Edit: It's a long opening post, so maybe I should state this briefly:

1) This is about a system-wide fix to avoid the Mixer and upsampling of 44/16 audio when playing through the Quad DAC.

2) This is not about avoiding UAPP or Neutron. I personally recommend UAPP as the best $8 anybody can spend if they care about sound quality on the V30.
 
Last edited:
  • Like
Reactions: BROKEN1981

BROKEN1981

Senior Member
Dec 27, 2013
1,922
874
ASUS ROG Phone 3
Google Pixel 6 Pro
So my settings sucks?
 

Attachments

  • Screenshot_2019-05-24-23-20-22.jpg
    Screenshot_2019-05-24-23-20-22.jpg
    209.8 KB · Views: 3,272

TheDannemand

Senior Member
Feb 12, 2008
1,168
1,181
So my settings sucks?

Well, yes and no ;)

Personally I wouldn't do it. I would set PowerAmp to output at 44.1KHz and 24-bit, which should avoid any re-sampling and just convert to 24-bit. Make sure you disable Dither (somewhere else in those Settings) so that it just adds zero bits in that 16-to-24-bit conversion. That way your 44/16 music should be sent unchanged to the DAC in 44/24 format.

But then you need to change your settings when you play HiRes music in PowerAmp, since otherwise it will be downsampled to 44.1KHz.

That said, as a fixed setting you are much better off letting PowerAmp upsample to 352Khz than letting the Android Mixer upsample to 48Khz. 44-to-352KHz is a harmonic upsampling (8x44=352) so it can be done perfectly, whereas 44-to-48KHz is just ugly. And when playing HiRes 88KHz and 176KHz music, it will be harmonically upsampled to 352Khz as well.

Ideally, PowerAmp would have had a way to only convert 44/16 to 44/24 and pass everything else through untouched. That's what UAPP does when it detects that it's running on a V30.

Another benefit of UAPP is it understands MQA and knows how to set a flag to enable the V30's hardware unfolding and rendering. (Note that you don't have to buy UAPP's optional MQA decoder for this.) With PowerAmp, the MQA will either be lost (if you re-sample or process the stream in any way) or ignored because the flag to enable MQA decoding won't be set.

Disclaimer: I don't use PowerAmp myself, so I cannot say if it it does something other than what those settings imply. I am completely open to corrections if any of my assumptions about it are wrong.

The DAC itself will upsample internally as part of so-called "noise shaping" to minimize the rounding errors that occur when trying to fit a digital sample into an analog sine wave. But we want to leave this process just to the DAC, and not add another step of upsampling (or any other digital modification) before sending music to the DAC. And particularly not an ugly upsampling like 44-to-48KHz, which simply cannot be done in a pretty way.
 
Last edited:

TheDannemand

Senior Member
Feb 12, 2008
1,168
1,181
Thanks for that detailed answer man, I appreciate it!

I tried neutron, hated the UI. I'll try out USB audio pro. Looks like it's a bit updated to MD. It's not as nice looking as PA, but that's ok lol.

I am the same: I tried Neutron and absolutely could not stand that UI. But I know some who love it. And they deserve credit for being first to crack the 48KHz upsampling on V30 (as I understand).

With UAPP I was instantly comfortable with its UI, features, and of course the sound quality -- the latter being as good as it can get, since it plays everything bit perfect and even supports MQA. If it could handle Tidal offline, I wouldn't even need a solution to bypass the Android Mixer, as that is the only big thing missing for me. Again, with others it's Qobuz offline or Spotify or some other music service.
 
  • Like
Reactions: BROKEN1981

BROKEN1981

Senior Member
Dec 27, 2013
1,922
874
ASUS ROG Phone 3
Google Pixel 6 Pro
I am the same: I tried Neutron and absolutely could not stand that UI. But I know some who love it. And they deserve credit for being first to crack the 48KHz upsampling on V30 (as I understand).

With UAPP I was instantly comfortable with its UI, features, and of course the sound quality -- the latter being as good as it can get, since it plays everything bit perfect and even supports MQA. If it could handle Tidal offline, I wouldn't even need a solution to bypass the Android Mixer, as that is the only big thing missing for me. Again, with others it's Qobuz offline or Spotify or some other music service.
Trying it out, I like it but have a few issues that are getting on my nerves.

1) no cross fade into the new track.
2) It separates my albums for whatever reason. PowerAmp will not do this. My tags are the way I want them. I did my own edits.

Edit, the EM album that's solo is also in the EM album collection. Just chose to list it 2 times.

Sent from my LG-H932 using XDA Labs
 

Attachments

  • Capture+_2019-06-03-05-48-01.jpg
    Capture+_2019-06-03-05-48-01.jpg
    270.9 KB · Views: 843
  • Capture+_2019-06-03-05-48-48.jpg
    Capture+_2019-06-03-05-48-48.jpg
    279.4 KB · Views: 820
  • Capture+_2019-06-03-05-49-18.jpg
    Capture+_2019-06-03-05-49-18.jpg
    279.2 KB · Views: 706
  • Capture+_2019-06-03-05-49-55.jpg
    Capture+_2019-06-03-05-49-55.jpg
    270.2 KB · Views: 658
Last edited:
  • Like
Reactions: TheDannemand

TheDannemand

Senior Member
Feb 12, 2008
1,168
1,181
Trying it out, I like it but have a few issues that are getting on my nerves.

1) no cross fade into the new track.
2) It separates my albums for whatever reason. PowerAmp will not do this. My tags are the way I want them. I did my own edits.

Edit, the EM album that's solo is also in the EM album collection. Just chose to list it 2 times.

I apologize for the tardy response. Swamped these days.

1) Ahh. I don't use cross fading myself, but I see what you mean, it's a valid request.

2) My entire music collection is carefully curated as well (manually edited tags) and I've never seen any problems with UAPP handling albums correctly. You could try Clearing the database and Scan again. But you probably already did...

I suggest you write to the Dev about both issues. You can either email [email protected] or post in their support thread on Head-Fi. I've found them very response to user requests and issues.

BTW, also check this recent Head-Fi post by @csglinux: It appears LG really screwed up the Quad DAC in Pie, so it now re-samples even some HiRes files (which all play perfectly on Oreo from most apps). It also sabotages UAPP in the process.

I don't know why LG is so hellbent on messing up music playback, when they spend good money putting a high-end audiophile grade DAC in their phones :rolleyes:
 
Last edited:

BROKEN1981

Senior Member
Dec 27, 2013
1,922
874
ASUS ROG Phone 3
Google Pixel 6 Pro
I apologize for the tardy response. Swamped these days.

1) Ahh. I don't use cross fading myself, but I see what you mean, it's a valid request.

2) My entire music collection is carefully curated as well (manually edited tags) and I've never seen any problems with UAPP handling albums correctly. You could try Clearing the database and Scan again. But you probably already did...

I suggest you write to the Dev about both issues. You can either email [email protected] or post in their support thread on Head-Fi. I've found them very response to user requests and issues.

BTW, also check this recent Head-Fi post by @csglinux: It appears LG really screwed up the Quad DAC in Pie, so it now re-samples even some HiRes files (which all play perfectly on Oreo from most apps). It also sabotages UAPP in the process.

I don't know why LG is so hellbent on messing up music playback, when they spend good money putting a high-end audiophile grade DAC in their phones :rolleyes:
I did send an email to the Dev. We tested a few things and then I guess he quickly made a newer version of the app and gave me a download link. It's a beta but he seen what the issue was and fixed it. Total time with emails and download link took about 30 minutes. I never expected the guy to reply so fast that a few minutes would go by with me not seeing his new email.

Awesome support! Just wish the UI would be gesture-based. Having to back out of a current playing album is a pain in the butt. PowerAmp definitely did this correctly.

Sent from my LG-H932 using XDA Labs
 
  • Like
Reactions: TheDannemand

DooMLoRD77

Member
Jul 19, 2018
40
30
I've edited three config files from US998 30b which I attached to this post. With this mod I always get 24bit and 44.1kHz output through Mixer. Now I can't hear the noise, but I'm curious if anyone can so please test it after making a system backup in TWRP. The mod contains the files without any script.
@TheDannemand and everyone who is interested.
I was trying to get direct output, but it's maybe impossible. I tried to have direct output instead of deep_buffer, but only UAPP wanted to use direct and other apps "moved" to primary output. Also the primary output does not tolerate any messing cause it's a p...y. So I'm not able to do what even @csglinux couldn't.

Solutions:
1) It's not possible due to most apps just don't support direct output even if we convert it to 24bit on the fly. Apps can use primary output instead of deep buffer but direct is like an isolated thing lol. I did enough tests with policy files to get bored of it.

2) Maybe I can try replacing or somewhat in mixer_paths_tavil.xml in vendor/etc to get the direct output. (?)

3) We need to do hard modifications in source codes and codec driver. Or just accept this Mixer and use it with some mod. :D So sad.
 

csglinux

New member
Jul 17, 2018
2
5
I've edited three config files from US998 30b which I attached to this post. With this mod I always get 24bit and 44.1kHz output through Mixer. Now I can't hear the noise, but I'm curious if anyone can so please test it after making a system backup in TWRP. The mod contains the files without any script.

@TheDannemand and everyone who is interested.
I was trying to get direct output, but it's maybe impossible. I tried to have direct output instead of deep_buffer, but only UAPP wanted to use direct and other apps "moved" to primary output. Also the primary output does not tolerate any messing cause it's a p...y. So I'm not able to do what even @csglinux couldn't.

Solutions:
1) It's not possible due to most apps just don't support direct output even if we convert it to 24bit on the fly. Apps can use primary output instead of deep buffer but direct is like an isolated thing lol. I did enough tests with policy files to get bored of it.

2) Maybe I can try replacing or somewhat in mixer_paths_tavil.xml in vendor/etc to get the direct output. (?)

3) We need to do hard modifications in source codes and codec driver. Or just accept this Mixer and use it with some mod. :D So sad.

Huge thanks to you, DoomLoRD77, for your efforts on this. Major props also to TheDanemmand, who has been relentlessly pursuing this little problem with LG's phones.

So, I took your config files, and voila, they work as promised, at least according to audio_flinger:

Output thread 0xeb1034c0, name AudioOut_15, tid 1804, type 0 (MIXER):
I/O handle: 21
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)

That's the good news. The bad news... for reasons I don't completely understand, all the exact same re-sampling artifacts are there, just as audible as before. (I think most of us are using the same test track here - Speak to Me, from The Dark Side Of The Moon.) Either audio_flinger is misreporting, or being fooled, or there's something else going on here that I don't understand.

I'd mentioned to some of the other headfi folks that Amazon's new lossless streaming service doesn't display these digital artifacts (it still doesn't sound quite as good as Tidal to my ears, but the SQ gap is much closer). Amazon re-samples everything on Android to 48 kHz using 32-bit float. I would have thought doing no resampling at all and shifting to 24-bit for the digital volume control would be enough, but apparently not. My best guess is those extra zeros we're packing into those remaining 8 bits aren't actually being used by the digital volume control.
 

TheDannemand

Senior Member
Feb 12, 2008
1,168
1,181
I've edited three config files from US998 30b which I attached to this post. With this mod I always get 24bit and 44.1kHz output through Mixer. Now I can't hear the noise, but I'm curious if anyone can so please test it after making a system backup in TWRP. The mod contains the files without any script.

@TheDannemand and everyone who is interested.
I was trying to get direct output, but it's maybe impossible. I tried to have direct output instead of deep_buffer, but only UAPP wanted to use direct and other apps "moved" to primary output. Also the primary output does not tolerate any messing cause it's a p...y. So I'm not able to do what even @csglinux couldn't.

Solutions:
1) It's not possible due to most apps just don't support direct output even if we convert it to 24bit on the fly. Apps can use primary output instead of deep buffer but direct is like an isolated thing lol. I did enough tests with policy files to get bored of it.

2) Maybe I can try replacing or somewhat in mixer_paths_tavil.xml in vendor/etc to get the direct output. (?)

3) We need to do hard modifications in source codes and codec driver. Or just accept this Mixer and use it with some mod. :D So sad.

Thanks a ton for your efforts here and for sharing these modified files!

Unfortunately I won't be able to test them myself, both because my V30 is still on Oreo (and I have no plans to update it yet) and because I am currently unrooted, waiting for LG to approve a warranty claim (at which they're dragging their feet).

I think with your work and @csglinux' feedback we have established that there is something going on beyond just the re-sampling of the Mixer. The fact your changes eliminated the noise you were hearing, but NOT the artifacts csglinux has reported, would indicate that maybe we have two different problems going on. And so far only playing DIRECT (bypassing the Mixer) solves both problems.

Re your point (3) I did actually spent quite a bit of time studying the source code for the ESS codec driver for the various LG models (es9218p.c and es9218p.h in the kernel source code). Interestingly, 44100 is NOT one of the sample rates listed in there as being supported. The rates and formats listed below are references in the snd_soc_dai_driver structure towards the end of the driver, with which the codec driver declares its capabilities. I've been puzzled how DIRECT play of 24/44 is even possible given this fact. But audio_flinger claims to do it -- and it sounds great when it does.

Code:
#define ES9218_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |  \
        SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |   \
        SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000 |   \
        SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000 | SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_384000 ) //|SNDRV_PCM_RATE_352800  TODO for dop128

#define ES9218_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \
        SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \
        SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE | \
        SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)

I am completely swamped with work at the moment, so I have no time at all to play (neither play music NOR tinker with my phone). I promise I will contribute more actively again once I have more time AND once I have a phone I can root.

Once again thanks a lot for your contribution! :good::good::good:
 
Last edited:

DooMLoRD77

Member
Jul 19, 2018
40
30

You're welcome. Yes, I played the Speak To Me song at the volume level of 10/75 from about 0:14 to 0:40. It can be possible that it's just misreporting, but it's weird that you hear the same artifacts and I hear just very very little noise instead of big. So we hear 2 different thing separately. From my experience it seems that the extra 8 bits are used for volume control. Or 24bit is more accurate for interpolating as you wrote something on head-fi. I will see more results later with GR09.

Also, thank you for the efforts and for this test!

I can mention an app for 16/44.1 lossless it's called D**zl#ad*r (replace "*" with "e" and "#" with "o"). I know it's not great to get files for free but I can play it offline through direct. It's for Android too and there are some funny facts how it can work.


You're welcome, too. Something is really weird about the Mixer as there is 2 kind of issue, indeed. I will just probably give up this soon for now, but I'm thankful for the support as I could achieve a small improvement.

If it's really a declaration as you said and I looked a bit into it then it's also weird how it can support 44.1 without resampling.

To replace Tidal offline there is an app above but it requires re-downloading everything. I solved it by automation. Life is just short to be always a good boy:silly:
 

Eneen

Member
Nov 28, 2019
8
12
Looks like deep-buffer is used for high latency low power output and this is ok for music. As I'm new I can't post proper link here, but googling "android audio deep buffer" gives answer.

To enable deep-buffer for music we need:
adb shell setprop audio.deep_buffer.media 1

So it looks like without it android is still using 48kHz from primary output and still resamples internally or I'm missing something. I own V30 but I'm not rooted yet so can't test this.

In the meantime I've looked into policy and there's additional MQA policy available. Maybe UAPP is using it to play MQA on LG?

I've also tried to use 16bit direct output from UAPP and there's noise on all recordings when V30 volume is low and I set my amplifier to almost full. This is unrealistic scenario but easily shows 16bit limitation. @DooMLoRD77, @TheDannemand could you check this UAPP setting if it plays through mixer or directly: MQA enabled and 16 bit hi-res driver audio format. Could tou also check if setting mixer into 32bit float mode works? This setting works for UAPP.
 
Last edited:

DooMLoRD77

Member
Jul 19, 2018
40
30
You are right that mixer is using 48khz upsampling either through deep buffer or primary output or call it whatever. Deep buffer for music is by default. Where did you found that MQA policy?

I can't help you now as my V30's motherboard is dying and it will take some time to replace it, but I can tell you that modifying the mixer to give 32bit output gives nothing just mute sound and lagging youtube playback maybe because of buffer size or idk.

You can have 32bit with direct, of course. Anyway, what recordings are giving noise? Vinyl? 16 bit does not have limitations like that. I guess you hear the noise generated by AVC in the Quad DAC. It has a high SNR but not enough if you amplify it with don't know what at max volume. I just assume that. I appreciate your interest.
 
  • Like
Reactions: TheDannemand

Eneen

Member
Nov 28, 2019
8
12
You are right that mixer is using 48khz upsampling either through deep buffer or primary output or call it whatever. Deep buffer for music is by default. Where did you found that MQA policy?

I can't help you now as my V30's motherboard is dying and it will take some time to replace it, but I can tell you that modifying the mixer to give 32bit output gives nothing just mute sound and lagging youtube playback maybe because of buffer size or idk.

You can have 32bit with direct, of course. Anyway, what recordings are giving noise? Vinyl? 16 bit does not have limitations like that. I guess you hear the noise generated by AVC in the Quad DAC. It has a high SNR but not enough if you amplify it with don't know what at max volume. I just assume that. I appreciate your interest.

Recordings from Tidal app (except MQAa) and when UAPP is set into 16bit mode inside "HiRes driver audio format" give noise. When I change this option to "Auto" then noise is gone. To hear it I just set sound level to 1/70 (lowest possible) and amplify rest on my amp. I'm not sure it's due to digital volume control or something else, but noise is there and I'm still above my NAD C372 noise level (100dB). How to check output path? I can do it myself but haven't found how...

If music is using deep buffer then your solution is very elegant IHMO and should work. Is youtube also using deep_buffer? Is deep_buffer always used or only when phone is sleeping?

MQA policies are inside /vendor/audio_output_policy.conf: direct_pcm_16_mqa and direct_pcm_24_mqa. As I see /etc/audio_policy.conf is depreciated but looks like /vendor/etc/audio_output_policy.conf is used and there are two different audio_policy_configuration.xml files. Is there documentation for android audio available?
 
Last edited:

DooMLoRD77

Member
Jul 19, 2018
40
30

I think direct does not support 16bit. It can be DVC or just the not really perfect mixer makes noise or what kind of interpolation error. You should have SDK platform tools to check it. Start inside an adb connection in cmd. Command: "adb shell" or "./adb shell" then "dumpsys media.audio_flinger" and it should read much thing about path and so on.

YouTube uses deep_buffer if it's available. It's used when music is played not only when sleeping. Primary is more like for notifications maybe some games. Sorry, what solution? LoL. 24bit modification?

I will check that policies again, thanks.
 
  • Like
Reactions: TheDannemand

Top Liked Posts

  • There are no posts matching your filters.
  • 9
    Is anybody aware of a system-wide solution to avoid the upsampling of 44.1KHz / 16-bit music to 48KHz?

    With system-wide, I mean a solution that does not rely on certain player apps such as UAPP or Neutron, which we know can do it, but only when playing from inside that app. A solution which works with all (or most) audio sources and apps, modifying the default system behavior of upsampling 44/16 to 48KHz when playing to the Quad DAC.

    Personally, I am looking for solutions to work with Tidal offline tracks. Others are looking for solutions to Qobuz, Spotify, Google Play Music or other apps.

    Do some of the custom ROMs have fixes for this? Are there policy file or build.prop changes that are proven to fix it?

    Googling and searching on XDA finds many references to Android's infamous 48KHz upsampling/re-sampling (SRC) but none that look to be actual, working solutions for our phones. I hope I am wrong and that there is a simple fix which I overlooked.


    Background

    The LG V series and G series (most models) are appreciated by audiophiles for their excellent ESS Sabre DAC (ES9218P, branded Quad DAC by LG). It can deliver amazing sound quality when paired with good headphones or IEMs (In-Ear-Monitors, earphones). (And no, that doesn't necessarily mean High-Impedance headphones/IEMs, but that's a whole other discussion.)

    V30 in particular has gained a rather large following among audiophiles, many of whom congregate on head-fi.org, where you will find a huge V30 thread, a growing V40 thread and a dedicated V30 Music apps, tricks and tips thread.

    When it comes to HiRes music (anything higher than 48KHz sample rate and anything 24-bit) most music apps play it correctly: Bit-perfect, without any processing or re-sampling, directly to the DAC -- exactly as audiophiles want it. A few apps are known to downsample HiRes music to Android's default sample rate of 48KHz, but those are the exception.

    However 44.1KHz / 16-bit music is always routed through Android's Mixer, which upsamples it to 48Khz. This causes artifacts that are audible to good ears, particularly when played on sensitive IEMs. Since 44/16 includes anything CD quality (whether compressed or uncompressed) that means most music in the world gets molested before it reaches the DAC.

    For whatever reason, LGs implementation of the ESS DAC throughout the V and G series have suffered from this inability to play 44/16 music without upsampling. It is the one thing that truly hampers their reputation among audiophiles (arguably even more so than the inability to select between gain modes, which is annoying, but not a deal breaker for most).

    This can be verified by inspecting the Output Thread of audio_flinger dumps, showing whether an output stream is played through the DIRECT path (not the MIXER path) and with the offloadable flag (sent straight to the DAC for decoding and rendering). Of course it can also be verified by listening for those artifacts.

    The last 1.5 years, audiophile V30 users have relied on UAPP or Neutron as music players because they are able to work around this upsampling. They do so by converting 44/16 format music to 44/24 on the fly, adding zero bits to convert 16-bit to 24-bit. Different from the 48KHz upsampling, this is a harmless conversion which doesn't affect audio quality. (Of course it's also much faster, requiring no interpolation.) And once music is in 44/24 format, it is no problem sending it directly to the DAC, as described above.

    We recently confirmed that PowerAmp also is able to do this correctly now (which wasn't always the case). But only if you configure it to convert all music to 44/24, which obviously isn’t desirable for HiRes.

    UAPP is my personal favorite, as it also supports streaming services Tidal, Qobuz and Google Play Music, in addition to network services and any PCM or DSD file you can throw at it. All of it pristinely bit-perfect. But it cannot support Tidal or Qobuz offline, which means when playing offline you are limited to HiRes music (only a small part of their catalog) unless you can tolerate the 48KHz upsampling of CD quality tracks in the Tidal/Qobuz apps.

    Head-Fi titan @csglinux and I have set out looking for a solution to this, along with other interested head-fi members. csglinux has been testing various policy and build.prop edits (so far no cigar), while I have been digging through the ESS driver source code from the kernel (but I am not set up to actually build the kernel).

    More background and discussion can be found in csglinux' V30 Music apps, tricks and tips thread on head-fi. I also recently had a brief (and more technical) discussion with @ctheanh about this over in the XDA V40 forum, starting here. Arguably those posts would be more suited here.

    We have several ideas, but it is a steep hill to climb, as none of us are Android developers. But before posting pages of what we have already tried, or dozens of audio_flinger dumps from various setups, we wanted to throw the topic out there for input. Again, maybe there is already a solution we have overlooked.

    Any input is much appreciated!

    TL;DR
    I personally recommend UAPP as the best $8 anybody can spend if they care about sound quality on their V30. This is not about avoiding that. But UAPP doesn't cover all scenarios, in particular offline Tidal and Qobuz.

    That's why we're looking for a system-wide fix (mod or custom ROM) that avoids the upsampling.
    4
    I've edited three config files from US998 30b which I attached to this post. With this mod I always get 24bit and 44.1kHz output through Mixer. Now I can't hear the noise, but I'm curious if anyone can so please test it after making a system backup in TWRP. The mod contains the files without any script.

    @TheDannemand and everyone who is interested.
    I was trying to get direct output, but it's maybe impossible. I tried to have direct output instead of deep_buffer, but only UAPP wanted to use direct and other apps "moved" to primary output. Also the primary output does not tolerate any messing cause it's a p...y. So I'm not able to do what even @csglinux couldn't.

    Solutions:
    1) It's not possible due to most apps just don't support direct output even if we convert it to 24bit on the fly. Apps can use primary output instead of deep buffer but direct is like an isolated thing lol. I did enough tests with policy files to get bored of it.

    2) Maybe I can try replacing or somewhat in mixer_paths_tavil.xml in vendor/etc to get the direct output. (?)

    3) We need to do hard modifications in source codes and codec driver. Or just accept this Mixer and use it with some mod. :D So sad.

    Huge thanks to you, DoomLoRD77, for your efforts on this. Major props also to TheDanemmand, who has been relentlessly pursuing this little problem with LG's phones.

    So, I took your config files, and voila, they work as promised, at least according to audio_flinger:

    Output thread 0xeb1034c0, name AudioOut_15, tid 1804, type 0 (MIXER):
    I/O handle: 21
    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)

    That's the good news. The bad news... for reasons I don't completely understand, all the exact same re-sampling artifacts are there, just as audible as before. (I think most of us are using the same test track here - Speak to Me, from The Dark Side Of The Moon.) Either audio_flinger is misreporting, or being fooled, or there's something else going on here that I don't understand.

    I'd mentioned to some of the other headfi folks that Amazon's new lossless streaming service doesn't display these digital artifacts (it still doesn't sound quite as good as Tidal to my ears, but the SQ gap is much closer). Amazon re-samples everything on Android to 48 kHz using 32-bit float. I would have thought doing no resampling at all and shifting to 24-bit for the digital volume control would be enough, but apparently not. My best guess is those extra zeros we're packing into those remaining 8 bits aren't actually being used by the digital volume control.
    4
    I've edited three config files from US998 30b which I attached to this post. With this mod I always get 24bit and 44.1kHz output through Mixer. Now I can't hear the noise, but I'm curious if anyone can so please test it after making a system backup in TWRP. The mod contains the files without any script.
    @TheDannemand and everyone who is interested.
    I was trying to get direct output, but it's maybe impossible. I tried to have direct output instead of deep_buffer, but only UAPP wanted to use direct and other apps "moved" to primary output. Also the primary output does not tolerate any messing cause it's a p...y. So I'm not able to do what even @csglinux couldn't.

    Solutions:
    1) It's not possible due to most apps just don't support direct output even if we convert it to 24bit on the fly. Apps can use primary output instead of deep buffer but direct is like an isolated thing lol. I did enough tests with policy files to get bored of it.

    2) Maybe I can try replacing or somewhat in mixer_paths_tavil.xml in vendor/etc to get the direct output. (?)

    3) We need to do hard modifications in source codes and codec driver. Or just accept this Mixer and use it with some mod. :D So sad.
    3
    I think direct does not support 16bit. It can be DVC or just the not really perfect mixer makes noise or what kind of interpolation error. You should have SDK platform tools to check it. Start inside an adb connection in cmd. Command: "adb shell" or "./adb shell" then "dumpsys media.audio_flinger" and it should read much thing about path and so on.

    YouTube uses deep_buffer if it's available. It's used when music is played not only when sleeping. Primary is more like for notifications maybe some games. Sorry, what solution? LoL. 24bit modification?

    I will check that policies again, thanks.

    I've checked all important options from UAPP and compared to tidal app. Looks like you were right about 16bit, it indeed goes through mixer and deep_buffer despite of hibit driver selected:
    Code:
    Output thread 0xf0183b80, name AudioOut_15, tid 1797, type 0 (MIXER):
      I/O handle: 21
      Standby: no
      Sample rate: 48000 Hz
      HAL frame count: 1920
      HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
      HAL buffer size: 7680 bytes
      Channel count: 2
      Channel mask: 0x00000003 (front-left, front-right)
      Processing format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
      Processing frame size: 4 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: 1920
      Last write occurred (msecs): 35
      Total writes: 1624536
      Delayed writes: 0
      Blocked in write: yes
      Suspend count: 0
      Sink buffer : 0xf0837000
      Mixer buffer: 0xf0812000
      Effect buffer: 0xf0861000
      Fast track availMask=0xfe
      Standby delay ns=3000000000
      AudioStreamOut: 0xf1b2c550 flags 0x8 (AUDIO_OUTPUT_FLAG_DEEP_BUFFER)
      Frames written: 3119109120
      Suspended frames: 0
      Hal stream dump:
      Thread throttle time (msecs): 5237
      AudioMixer tracks: 0 
      Master mono: off
      No FastMixer
      Stream volumes in dB: 0:-10, 1:-inf, 2:-inf, 3:-33, 4:-28, 5:-inf, 6:-inf, 7:-inf, 8:-inf, 9:-96, 10:-30, 11:0, 12:0
      Normal mixer raw underrun counters: partial=0 empty=0

    But with MQA flag for LG it gets direct but it's worth noticing that noise remains, so most likely it's either 16bit noise floor or ESS AVC is not used for android mixer but digital one:
    Code:
    utput thread 0xf07d0000, name AudioOut_B45, tid 19826, type 1 (DIRECT):
      I/O handle: 2885
      Standby: no
      Sample rate: 44100 Hz
      HAL frame count: 3552
      HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
      HAL buffer size: 14208 bytes
      Channel count: 2
      Channel mask: 0x00000003 (front-left, front-right)
      Processing format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
      Processing frame size: 4 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: 3552
      Last write occurred (msecs): 24
      Total writes: 63
      Delayed writes: 0
      Blocked in write: yes
      Suspend count: 0
      Sink buffer : 0xefd17800
      Mixer buffer: 0xeef5b000
      Effect buffer: 0xeeeb3000
      Fast track availMask=0xfe
      Standby delay ns=3000000000
      AudioStreamOut: 0xf079b438 flags 0x200001 (AUDIO_OUTPUT_FLAG_DIRECT)
      Frames written: 223776
      Suspended frames: 0
      Hal stream dump:
      Stream volumes in dB: 0:-10, 1:-inf, 2:-inf, 3:-33, 4:-33, 5:-inf, 6:-inf, 7:-inf, 8:-inf, 9:-96, 10:-32, 11:0, 12:0
      Normal mixer raw underrun counters: partial=0 empty=0

    Auto mode goes as 24bit_packed:
    Code:
    Output thread 0xeef68000, name AudioOut_B3D, tid 19714, type 1 (DIRECT):
      I/O handle: 2877
      Standby: no
      Sample rate: 44100 Hz
      HAL frame count: 3552
      HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
      HAL buffer size: 21312 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: 3552
      Last write occurred (msecs): 44
      Total writes: 51
      Delayed writes: 0
      Blocked in write: yes
      Suspend count: 0
      Sink buffer : 0xef2a7000
      Mixer buffer: 0xef2ae000
      Effect buffer: 0xef4cf000
      Fast track availMask=0xfe
      Standby delay ns=3000000000
      AudioStreamOut: 0xf079b398 flags 0x1 (AUDIO_OUTPUT_FLAG_DIRECT)
      Frames written: 181152
      Suspended frames: 0
      Hal stream dump:
      Stream volumes in dB: 0:-10, 1:-inf, 2:-inf, 3:-33, 4:-33, 5:-inf, 6:-inf, 7:-inf, 8:-inf, 9:-96, 10:-32, 11:0, 12:0
      Normal mixer raw underrun counters: partial=0 empty=0

    And this is same as MQA playback for Tidal app:
    Code:
    Output thread 0xeef2e000, name AudioOut_BC5, tid 22337, type 1 (DIRECT):
      I/O handle: 3013
      Standby: no
      Sample rate: 48000 Hz
      HAL frame count: 3840
      HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
      HAL buffer size: 23040 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: 3840
      Last write occurred (msecs): 37
      Total writes: 255
      Delayed writes: 0
      Blocked in write: yes
      Suspend count: 0
      Sink buffer : 0xeeee9000
      Mixer buffer: 0xeb11a000
      Effect buffer: 0xeb123000
      Fast track availMask=0xfe
      Standby delay ns=3000000000
      AudioStreamOut: 0xf079b410 flags 0x200001 (AUDIO_OUTPUT_FLAG_DIRECT)
      Frames written: 979200
      Suspended frames: 0
      Hal stream dump:
      Stream volumes in dB: 0:-10, 1:-inf, 2:-inf, 3:-28, 4:-33, 5:-inf, 6:-inf, 7:-inf, 8:-inf, 9:-96, 10:-32, 11:0, 12:0
      Normal mixer raw underrun counters: partial=0 empty=0

    In the meantime I've tried to ask Tidal about resampling and here is answer:
    With the TIDAL app streaming, there are frequency and bitrate limitations on Android devices when using DACs. The TIDAL app along is unable to avoid resampling that is done by Android devices.

    1. I'd like to ask Tidal to add direct mode same as they've got for MQA playback, but I've got no idea what to write. This is what I've suggested on head-fi V30 tips and tricks thread.
    2. It would be nice to somehow figure out if there is or there's no digital volume control for mixer
    3. Is there reason why haven't you changed primary_output frequency but deep_buffer only? Maybe we need both to be 44100/24?
    4. Are there any diagrams of android audio system? I'm curious how audio stream goes and if it's resampled by mixer even if stream matches deep_buffer output parameters.
    3
    I've edited three config files from US998 30b which I attached to this post. With this mod I always get 24bit and 44.1kHz output through Mixer. Now I can't hear the noise, but I'm curious if anyone can so please test it after making a system backup in TWRP. The mod contains the files without any script.

    @TheDannemand and everyone who is interested.
    I was trying to get direct output, but it's maybe impossible. I tried to have direct output instead of deep_buffer, but only UAPP wanted to use direct and other apps "moved" to primary output. Also the primary output does not tolerate any messing cause it's a p...y. So I'm not able to do what even @csglinux couldn't.

    Solutions:
    1) It's not possible due to most apps just don't support direct output even if we convert it to 24bit on the fly. Apps can use primary output instead of deep buffer but direct is like an isolated thing lol. I did enough tests with policy files to get bored of it.

    2) Maybe I can try replacing or somewhat in mixer_paths_tavil.xml in vendor/etc to get the direct output. (?)

    3) We need to do hard modifications in source codes and codec driver. Or just accept this Mixer and use it with some mod. :D So sad.

    Thanks a ton for your efforts here and for sharing these modified files!

    Unfortunately I won't be able to test them myself, both because my V30 is still on Oreo (and I have no plans to update it yet) and because I am currently unrooted, waiting for LG to approve a warranty claim (at which they're dragging their feet).

    I think with your work and @csglinux' feedback we have established that there is something going on beyond just the re-sampling of the Mixer. The fact your changes eliminated the noise you were hearing, but NOT the artifacts csglinux has reported, would indicate that maybe we have two different problems going on. And so far only playing DIRECT (bypassing the Mixer) solves both problems.

    Re your point (3) I did actually spent quite a bit of time studying the source code for the ESS codec driver for the various LG models (es9218p.c and es9218p.h in the kernel source code). Interestingly, 44100 is NOT one of the sample rates listed in there as being supported. The rates and formats listed below are references in the snd_soc_dai_driver structure towards the end of the driver, with which the codec driver declares its capabilities. I've been puzzled how DIRECT play of 24/44 is even possible given this fact. But audio_flinger claims to do it -- and it sounds great when it does.

    Code:
    #define ES9218_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |  \
            SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |   \
            SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000 |   \
            SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000 | SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_384000 ) //|SNDRV_PCM_RATE_352800  TODO for dop128
    
    #define ES9218_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \
            SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE | \
            SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE | \
            SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)

    I am completely swamped with work at the moment, so I have no time at all to play (neither play music NOR tinker with my phone). I promise I will contribute more actively again once I have more time AND once I have a phone I can root.

    Once again thanks a lot for your contribution! :good::good::good: