Database Users

Oreo and 16/44.1kHz, downsampled or not? - LG V20 Questions & Answers

Hello,
To get bit-perfect audio on stock LG player you have to edit audio.offload.pcm.16bit.enable=true in build.prop.
Is that fixed in Oreo? My only use for root is to enable that option.
Can anyone check it out with adb shell dumpsys media.audio_flinger when playing a 16/44.1 with stock LG music player through headphones and check DIRECT output?
Should look like the right column if it's working correctly, or as the left one if it's resampling.
{
"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"
}
Thanks!
Emil

Oreo doesn't offer that build.prop variable anymore, I just noticed that last night as I was playing around with some plain old 16 bit/44.1 kHz stuff (straight CD rips to FLAC). The only way so far - after reading a few thousand posts in threads over at Head-Fi - to get pure DIRECT audio from CD standard files (again, 16 bit/44.1 kHz material - is to use an app called USB Audio Player PRO aka UAPP which bypasses the internal Android SRC subsystem entirely and feeds the digital data stream directly to the ESS DAC.
There's a few players, like the Hiby Music Player, which claim to do this but after testing it last night using the exact same source material, I noted it wasn't working in DIRECT mode but MIXER and upsampling to 48 kHz which is where all the problems come from. The Hiby app is free, UAPP isn't and I don't think (personally) that it's worth $7.99 but that's just me I guess.
Also, I've noted the LG Music Player tends to be rather picky sometimes: I can start playing a 24 bit/96 kHz FLAC file, and I'll see DIRECT output as expected, but if I then start playing a 16 bit/44.1 kHz FLAC file immediately after the "Hi-Res" file it will drop back to MIXER operation - but then if I go and play that 24/96 file again immediately after that I still see MIXER operation meaning the LG Music Player isn't going back into DIRECT mode as I would expect it to.
My H918 is running the rooted Oreo ROM, and it has the one config altered to force the DAC to always be operational aka "high impedance mode" even if the listening tools don't trigger the high impedance aspect. I have some Koss KSC-75 earclips which trigger that mode but my main listening hardware at the moment are Monoprice 9927 earbuds which sound really damned good but they're 32 Ohms so I had to make that mod to get the DAC to always be functional for them).
I've got a few bucks in Google Play credit because of completing the Google Rewards surveys, I suppose I should just buy UAPP and be done with it once and for all because that apparently is the only app available that will always push the digital data stream directly to the DAC and we get it "bit perfect" with no down or upsampling occurring anywhere in the path.
But Oreo removed the 16bit variable and might have replaced it with one that says this:
audio.offload.pcm.enable=true
so while I can't offer any conclusive proof that it's a similar value to the 16bit one from Nougat, I can't really say I've seen any evidence of it in action. My audio files are all in Opus format (16 bit/48 kHz) so they should be passed to the DAC without any kind of SRC conversion at all taking place. I altered the extension from .opus to .ogg and the LG Music Player can see the files but they still don't get passed in DIRECT mode to the DAC so it's not a big hassle.
The quad DAC in the V20 is damned nice, really, but it's entirely too picky in terms of how it handles audio formats, it should just be ON or OFF, period, for everything and that's that.

br0adband said:
Oreo doesn't offer that build.prop variable anymore, I just noticed that last night as I was playing around with some plain old 16 bit/44.1 kHz stuff (straight CD rips to FLAC). The only way so far - after reading a few thousand posts in threads over at Head-Fi - to get pure DIRECT audio from CD standard files (again, 16 bit/44.1 kHz material - is to use an app called USB Audio Player PRO aka UAPP which bypasses the internal Android SRC subsystem entirely and feeds the digital data stream directly to the ESS DAC.
Also, I've noted the LG Music Player tends to be rather picky sometimes: I can start playing a 24 bit/96 kHz FLAC file, and I'll see DIRECT output as expected, but if I then start playing a 16 bit/44.1 kHz FLAC file immediately after the "Hi-Res" file it will drop back to MIXER operation - but then if I go and play that 24/96 file again immediately after that I still see MIXER operation meaning the LG Music Player isn't going back into DIRECT mode as I would expect it to.
But Oreo removed the 16bit variable and might have replaced it with one that says this:
audio.offload.pcm.enable=true
The quad DAC in the V20 is damned nice, really, but it's entirely too picky in terms of how it handles audio formats, it should just be ON or OFF, period, for everything and that's that.
Click to expand...
Click to collapse
I see, thank you for your time to answer my question!
I've also seen the posts about UAPP, but considering I'm having a great experience with the LG music player(Did you notice mixer/direct problem in Nougat with highres/rebook files?) I can't bring myself to shell out the money for UAPP.
I agree, the DAC is a beaut. It's a shame LG can't 'handle' it.
But, just to conclude, do you get 16/44.1kHz playback in DIRECT mode on Oreo in both UAPP & LG music player(albeit picky)?

Well I don't have UAPP, I'm considering getting it since it would only cost me about $3 I suppose (I have about $4.72 in Rewards credits). I suppose it couldn't hurt to own it because it's got a good reputation, has a ton of features (not that I care about most of them), and the developer is very active over at Head-Fi and responds to bugs and glitches very fast in terms of updates to quash 'em.
I'll go ahead and get UAPP and do some testing and see what happens with various source material and report back in a bit with some results. I don't suspect it's going to make a huge difference for me personally, my aging ears have lost any really good high frequency response long ago so it's tough for me to literally hear some aspects that so many people are looking for.
One thing that I was impressed with was listening to a 24/96 file earlier with these Monoprice 9927 IEMs: Rush is my favorite band forever and I was listening to a 24/96 version of Vapor Trails Remixed, specifically the song "Ghost Rider" just after it starts. When the opening vocals change into the hard hitting thump of the song, Geddy's bass playing jumps out, literally, and is crystal clear and I hear that bass and the fingerings and playing clearer than ever before. Now, I'm not saying that's caused by the V20, the HiFi DAC, or even the Monoprice 9927s (they truly are amazing for the ~$7 I paid for them, seriously), or the 24/96 nature of the audio file itself but I can say I've listened to that album (it is a remix of course and so that could have something to do with it) over the years and never noticed the bass notes with that level of clarity before.
Suffice to say I'm happy to still be able to hear new things, sure.
I'll do some testing and see what happens with UAPP and post some results later.

OK, some reports. Variety of music in FLAC files from 16/44 through 24/192 including some Opus 128Kbps files which are 16/48 natively (from 16/44 source material originally). This again is on Oreo on the H918 using the stock LG Music Player and using USB Audio Player PRO aka UAPP (I'll just call it UAPP from now on) with the HiFi DAC enabled permanently (meaning the high impedance mode is forced into enabled state by altering a variable in the build.prop file).
When UAPP was installed and first used it detected the HiFi DAC in my V20 as expected and I used the defaults from that point on. I did experiment with the "Bit Perfect" setting and it forces everything straight to the DAC without issues, even when I was using UAPP to load a Shoutcast stream it went straight through which was impressive really.
So here goes...
1st Track
Alice In Chains - "Over Now" from their Unplugged album
Opus 128Kbps encoding 16 bit 48 kHz - renamed the file to Over Now.ogg so the LG Music Player and UAPP can "see" the file to play it, neither of them respect the .opus extension
LG Music Player
Code:
Output thread 0xf1903340, name AudioOut_1D, tid 1646, type 0 (MIXER):
I/O handle: 29
Standby: yes
Sample rate: 48000 Hz
HAL frame count: 768
HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
HAL buffer size: 3072 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x5 (AUDIO_FORMAT_PCM_FLOAT)
Processing frame size: 8 bytes
Pending config events: none
Output device: 0 (AUDIO_DEVICE_NONE)
Input device: 0 (AUDIO_DEVICE_NONE)
UAPP (default settings)
Code:
Output thread 0xf0b86000, name AudioOut_18D, tid 18928, type 1 (DIRECT):
I/O handle: 397
Standby: no
Sample rate: 48000 Hz
HAL frame count: 1920
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 11520 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)
2nd Track
Rush - "Ghost Rider" from Vapor Trails Remixed
FLAC 16 bit 44.1 kHz direct CD rip
LG Music Player
Code:
Output thread 0xf1903340, name AudioOut_1D, tid 1646, type 0 (MIXER):
I/O handle: 29
Standby: yes
Sample rate: 48000 Hz
HAL frame count: 768
HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
HAL buffer size: 3072 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x5 (AUDIO_FORMAT_PCM_FLOAT)
Processing frame size: 8 bytes
Pending config events: none
Output device: 0 (AUDIO_DEVICE_NONE)
Input device: 0 (AUDIO_DEVICE_NONE)
UAPP (default settings)
Code:
Output thread 0xf0b8c000, name AudioOut_195, tid 19418, type 1 (DIRECT):
I/O handle: 405
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)
3rd Track
Rush - "Subdivisions" from Signals
FLAC 24 bit 96 kHz (a most excellent vinyl encode done by PBTHAL)
LG Music Player
Code:
Output thread 0xf0bf6000, name AudioOut_19D, tid 19609, type 1 (DIRECT):
I/O handle: 413
Standby: no
Sample rate: 96000 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: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
Input device: 0 (AUDIO_DEVICE_NONE)
UAPP (default settings)
Code:
Output thread 0xf15fd000, name AudioOut_1B5, tid 20155, type 1 (DIRECT):
I/O handle: 437
Standby: no
Sample rate: 96000 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: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
Input device: 0 (AUDIO_DEVICE_NONE)
4th Track
Eric Johnson - "Cliffs Of Dover" from Ah Via Musicom
FLAC 24 bit 192 kHz HDTracks purchase
LG Music Player
Code:
Output thread 0xf0be3000, name AudioOut_1BD, tid 20300, type 1 (DIRECT):
I/O handle: 445
Standby: no
Sample rate: 192000 Hz
HAL frame count: 7680
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 46080 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)
UAPP (default settings)
Code:
Output thread 0xeec2c000, name AudioOut_1C5, tid 20521, type 1 (DIRECT):
I/O handle: 453
Standby: no
Sample rate: 192000 Hz
HAL frame count: 7680
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 46080 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)
So the basic gist is that as far as the LG Music Player is concerned, any and all 44.1 kHz content like the 2nd track, a pure 16 bit 44.1 kHz data stream, is upconverted/upsampled to 48 kHz because that's what happens in the Android SRC subsystem: any 44.1 kHz content gets bumped to 48 kHz which is where most of the "purists" have the biggest issue. Track 1, the Opus file, with its native 48 kHz sampling rate, does go to the Snapdragon DAC as noted by the MIXER tag but since it's at that sample rate it goes untouched. UAPP passes basically everything to the DAC untouched then it shows DIRECT as expected as that same data is passed directly to the DAC.
If I put UAPP in "Bit Perfect" mode everything goes to the DAC untouched, even by UAPP's internal EQ (which I don't use anyway) and any other potential processing - UAPP has support for a parametric EQ (an additional $1.99 USD purchase) and something else called MorphIt which allows you to mimic the audio signature of another pair of headphones/IEMs with whatever you happen to be using as long as they're on the list of supported hardware.
I was surprised that UAPP would push the Shoutcast audio streams straight through as well but it does so that's pretty damned cool. I have no use for Tidal or Qobuz (other Hi-Res audio streaming services), but it does support Google Play Music interestingly enough and I do have a ton of 320 Kbps MP3 files stored there but I doubt I'd find it useful since I already have that content as Opus anyway (same source material, my old 2300+ CD collection). Guess some people can now listen to their favorite podcasts "bit perfect," go figure.
UAPP offers so much in terms of network connectivity, UPNP server ability and connections, DLNA support too, I guess it was worth the ~$3.50 I paid for it out of pocket as the rest was done with Rewards survey credits. I'll more than likely just leave it in "Bit Perfect" mode from now on since there's really no reason not to use that mode; I don't use EQ, ever, and these Monoprice 9927's are seriously awesome, really. The Head-Fi thread on them has been around since November 2011 and has a lot of great info and reviews and even a few mods - I placed a piece of Scotch tape on mine to cover the tiny port hole next to the stem and it made all the difference in the world in terms of audio quality for me. For the ~$7-8 they cost, they are worth that and a whole lot more, damned awesome kick-ass low cost IEMs, something that most of us never believed possible.
Anyway, hope this helps. I can't say UAPP would be worth the cost to you or anyone else, but so far considering the "Bit Perfect" mode for me and my purposes, I guess that makes it worth the cost to ensure that I'll always hear things exactly as they should sound in terms of them being untouched as a bit-stream directly to the ESS DAC.
Good luck, and happy listening...

Many thanks!
Looks like I'm good to go on the Oreo update and can still retain the bit-perfect sound just with a new music player.
And I agree, there are a few earbuds available for cheap that will really knock your socks off! I have the Ve Monks Plus and they are just wonderful for the $5 price.

Many thanks for the recommendation.
I too had some Google credits sitting there so I had virtually 1/2 paid for.
The Bit Perfect is quite remarkable. Totally impressed with it.
I've always been happy with my V20 since I bought it (Audio wise), I have a variety of earbuds that I use (nothing high $) but my daily drivers are Xiaomi Hybrid dual drivers.
I thought that the audio quality seemed slightly better after the Oreo update, then now with the USB Audio Player Pro added to the mix it's pretty awesome.
The Bit Perfect mode is pretty much how I like my audio to sound (balanced).
Sure hope one day that LG decides to come full circle and make a newer version of the V20 with everything that makes this particular version so great.
- removable SD card
- removable battery
- HQ audio dac (playback and recording)
- aluminum chassis (no glass back)
- good camera
- true dual SIM model available (not hybrid)
br0adband said:
OK, some reports. Variety of music in FLAC files from 16/44 through 24/192 including some Opus 128Kbps files which are 16/48 natively (from 16/44 source material originally). This again is on Oreo on the H918 using the stock LG Music Player and using USB Audio Player PRO aka UAPP (I'll just call it UAPP from now on) with the HiFi DAC enabled permanently (meaning the high impedance mode is forced into enabled state by altering a variable in the build.prop file).
When UAPP was installed and first used it detected the HiFi DAC in my V20 as expected and I used the defaults from that point on. I did experiment with the "Bit Perfect" setting and it forces everything straight to the DAC without issues, even when I was using UAPP to load a Shoutcast stream it went straight through which was impressive really.
So here goes...
1st Track
Alice In Chains - "Over Now" from their Unplugged album
Opus 128Kbps encoding 16 bit 48 kHz - renamed the file to Over Now.ogg so the LG Music Player and UAPP can "see" the file to play it, neither of them respect the .opus extension
LG Music Player
Code:
Output thread 0xf1903340, name AudioOut_1D, tid 1646, type 0 (MIXER):
I/O handle: 29
Standby: yes
Sample rate: 48000 Hz
HAL frame count: 768
HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
HAL buffer size: 3072 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x5 (AUDIO_FORMAT_PCM_FLOAT)
Processing frame size: 8 bytes
Pending config events: none
Output device: 0 (AUDIO_DEVICE_NONE)
Input device: 0 (AUDIO_DEVICE_NONE)
UAPP (default settings)
Code:
Output thread 0xf0b86000, name AudioOut_18D, tid 18928, type 1 (DIRECT):
I/O handle: 397
Standby: no
Sample rate: 48000 Hz
HAL frame count: 1920
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 11520 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)
2nd Track
Rush - "Ghost Rider" from Vapor Trails Remixed
FLAC 16 bit 44.1 kHz direct CD rip
LG Music Player
Code:
Output thread 0xf1903340, name AudioOut_1D, tid 1646, type 0 (MIXER):
I/O handle: 29
Standby: yes
Sample rate: 48000 Hz
HAL frame count: 768
HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
HAL buffer size: 3072 bytes
Channel count: 2
Channel mask: 0x00000003 (front-left, front-right)
Processing format: 0x5 (AUDIO_FORMAT_PCM_FLOAT)
Processing frame size: 8 bytes
Pending config events: none
Output device: 0 (AUDIO_DEVICE_NONE)
Input device: 0 (AUDIO_DEVICE_NONE)
UAPP (default settings)
Code:
Output thread 0xf0b8c000, name AudioOut_195, tid 19418, type 1 (DIRECT):
I/O handle: 405
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)
3rd Track
Rush - "Subdivisions" from Signals
FLAC 24 bit 96 kHz (a most excellent vinyl encode done by PBTHAL)
LG Music Player
Code:
Output thread 0xf0bf6000, name AudioOut_19D, tid 19609, type 1 (DIRECT):
I/O handle: 413
Standby: no
Sample rate: 96000 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: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
Input device: 0 (AUDIO_DEVICE_NONE)
UAPP (default settings)
Code:
Output thread 0xf15fd000, name AudioOut_1B5, tid 20155, type 1 (DIRECT):
I/O handle: 437
Standby: no
Sample rate: 96000 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: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
Input device: 0 (AUDIO_DEVICE_NONE)
4th Track
Eric Johnson - "Cliffs Of Dover" from Ah Via Musicom
FLAC 24 bit 192 kHz HDTracks purchase
LG Music Player
Code:
Output thread 0xf0be3000, name AudioOut_1BD, tid 20300, type 1 (DIRECT):
I/O handle: 445
Standby: no
Sample rate: 192000 Hz
HAL frame count: 7680
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 46080 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)
UAPP (default settings)
Code:
Output thread 0xeec2c000, name AudioOut_1C5, tid 20521, type 1 (DIRECT):
I/O handle: 453
Standby: no
Sample rate: 192000 Hz
HAL frame count: 7680
HAL format: 0x6 (AUDIO_FORMAT_PCM_24_BIT_PACKED)
HAL buffer size: 46080 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)
So the basic gist is that as far as the LG Music Player is concerned, any and all 44.1 kHz content like the 2nd track, a pure 16 bit 44.1 kHz data stream, is upconverted/upsampled to 48 kHz because that's what happens in the Android SRC subsystem: any 44.1 kHz content gets bumped to 48 kHz which is where most of the "purists" have the biggest issue. Track 1, the Opus file, with its native 48 kHz sampling rate, does go to the Snapdragon DAC as noted by the MIXER tag but since it's at that sample rate it goes untouched. UAPP passes basically everything to the DAC untouched then it shows DIRECT as expected as that same data is passed directly to the DAC.
If I put UAPP in "Bit Perfect" mode everything goes to the DAC untouched, even by UAPP's internal EQ (which I don't use anyway) and any other potential processing - UAPP has support for a parametric EQ (an additional $1.99 USD purchase) and something else called MorphIt which allows you to mimic the audio signature of another pair of headphones/IEMs with whatever you happen to be using as long as they're on the list of supported hardware.
I was surprised that UAPP would push the Shoutcast audio streams straight through as well but it does so that's pretty damned cool. I have no use for Tidal or Qobuz (other Hi-Res audio streaming services), but it does support Google Play Music interestingly enough and I do have a ton of 320 Kbps MP3 files stored there but I doubt I'd find it useful since I already have that content as Opus anyway (same source material, my old 2300+ CD collection). Guess some people can now listen to their favorite podcasts "bit perfect," go figure.
UAPP offers so much in terms of network connectivity, UPNP server ability and connections, DLNA support too, I guess it was worth the ~$3.50 I paid for it out of pocket as the rest was done with Rewards survey credits. I'll more than likely just leave it in "Bit Perfect" mode from now on since there's really no reason not to use that mode; I don't use EQ, ever, and these Monoprice 9927's are seriously awesome, really. The Head-Fi thread on them has been around since November 2011 and has a lot of great info and reviews and even a few mods - I placed a piece of Scotch tape on mine to cover the tiny port hole next to the stem and it made all the difference in the world in terms of audio quality for me. For the ~$7-8 they cost, they are worth that and a whole lot more, damned awesome kick-ass low cost IEMs, something that most of us never believed possible.
Anyway, hope this helps. I can't say UAPP would be worth the cost to you or anyone else, but so far considering the "Bit Perfect" mode for me and my purposes, I guess that makes it worth the cost to ensure that I'll always hear things exactly as they should sound in terms of them being untouched as a bit-stream directly to the ESS DAC.
Good luck, and happy listening...
Click to expand...
Click to collapse

One additional thing about Bit Perfect mode with UAPP: ReplayGain has no effect anymore, it won't honor any RG settings embedded in files so if you use RG to make sure all your music files are at roughly the same volume, with Bit Perfect mode those settings will be ignored completely.
Learned about this yesterday when I noticed I was reaching for the volume controls more than usual. I did research over at Head-Fi and the developer pointed out that by using RG settings you're not "bit perfect" anymore and listening to a modified version - even if it's just by adjusting the volume - of the bits as presented in their original format so, now I know.
I don't use Bit Perfect mode constantly, was just using it for some testing purposes. I know the audio data is being sent to the DAC and bypassing the Android SRC subsystem so that's enough for me, but having the RG data to keep me from having to adjust the volume basically at all is more useful in most situations.

br0adband said:
One additional thing about Bit Perfect mode with UAPP: ReplayGain has no effect anymore, it won't honor any RG settings embedded in files so if you use RG to make sure all your music files are at roughly the same volume, with Bit Perfect mode those settings will be ignored completely.
Learned about this yesterday when I noticed I was reaching for the volume controls more than usual. I did research over at Head-Fi and the developer pointed out that by using RG settings you're not "bit perfect" anymore and listening to a modified version - even if it's just by adjusting the volume - of the bits as presented in their original format so, now I know.
I don't use Bit Perfect mode constantly, was just using it for some testing purposes. I know the audio data is being sent to the DAC and bypassing the Android SRC subsystem so that's enough for me, but having the RG data to keep me from having to adjust the volume basically at all is more useful in most situations.
Click to expand...
Click to collapse
That's a shame, but I personally can live with it, considering I mostly listening to full albums.
I've not upgraded to Oreo yet, I'm just trying to find out all the things I've done to my device that required root.
I might wait until I can update and keep root, if there's to much done that I can't live without.

V20 can do bit-perfect for both 16/44.1 mp3 and aac (by offloading) while it is upsampling to 16/48 for 14/44.1 flac
Its pcm 16 driver may only do 48-integer multiple.

Related

Dear friends,
I really hope someone can help me with my never-ending struggle with CorePlayer 1.1.1.
It pauses every few seconds, for buffering I guess.
The video (DivX AVI) is stored on the MicroDrive. Now what are the setting I need in the preferences - buffering menu? I tried a lot of different values, some of them work better than others, but the lags remain.
Right now it's:
Normal buffer size: 2400 KB
Preload at underrun: 70.0%
Preload for audio: 64 KB
Microdrive mode: ENABLED
Microdrive buffer size: 24000 KB
Microdrive starts at: 1472 KB
The file details are:
DivX AVI
940063 KB in size
Video: MPEG-4 video
Core: CoreASP
Video Size: 640 x 362
Frame Rate: 25.0
Audio: MP3
Codec: CoreMP3
Audio Format: 44100 Hz 2 Ch
Data Bit Rate: 192 kbit/s
---
Something else that's strange:
CorePlayer doesn't remember my zoom setting in options - zoom.
E.g. when I set "Fill Screen" it's back to "Fit Best" after closing CorePlayer.
Didn't have that with TCPMP. Is that a known thing or is there a trick?
Thanks people!!

Update: some of the video's play FINE when I mute the audio!!
How to work with that?
CorePlayer still doesn't remember the zoom setting though.....

hey mate
i had the same issue with coreplayer some time ago. i found a thread somewhere in the athena section about this. i can't find it anymore but here's the settings that i did based on that thread. basically it was the recommended settings...
=============================
buffering page
Normal buffer size: 2400 KB (same)
Preload at underrun: 70.0% (same)
Preload for audio: 64 KB (same)
Microdrive mode: ENABLED (same)
Microdrive buffer size: 24000 KB (set at 16000)
Microdrive starts at: 1472 KB (same)
============================
video page
video output "raw frame buffer"
video quality high
============================
advanced page
d-pad follow screen (enabled)
use system volume (enabled)
benchmark from current position (enabled)
manual a/v offset 0.00
soft-drop tolerance 0.055
hard-drop tolerance 0.700
=============================
ati imageon page
enable all of them (6 items)
=============================
============================
hope that helps. for me those settings give me the best video quality while at the same time in sync with the sound. i used to have the same issues you have where the video stops while the sound is still there. but after switching to the settings above, i've had no issues ever since. i can even watch direct dvd rips on the sd card and there are no issues whatsover.
cheers
JayRayMee.NL said:
Dear friends,
I really hope someone can help me with my never-ending struggle with CorePlayer 1.1.1.
It pauses every few seconds, for buffering I guess.
The video (DivX AVI) is stored on the MicroDrive. Now what are the setting I need in the preferences - buffering menu? I tried a lot of different values, some of them work better than others, but the lags remain.
Right now it's:
Normal buffer size: 2400 KB
Preload at underrun: 70.0%
Preload for audio: 64 KB
Microdrive mode: ENABLED
Microdrive buffer size: 24000 KB
Microdrive starts at: 1472 KB
The file details are:
DivX AVI
940063 KB in size
Video: MPEG-4 video
Core: CoreASP
Video Size: 640 x 362
Frame Rate: 25.0
Audio: MP3
Codec: CoreMP3
Audio Format: 44100 Hz 2 Ch
Data Bit Rate: 192 kbit/s
---
Something else that's strange:
CorePlayer doesn't remember my zoom setting in options - zoom.
E.g. when I set "Fill Screen" it's back to "Fit Best" after closing CorePlayer.
Didn't have that with TCPMP. Is that a known thing or is there a trick?
Thanks people!!
Click to expand...
Click to collapse

Thanks.
That direct dvd rips you play, at what resolution are those?

not sure, but these are avi files that i downloaded straight from the internet. average size is around 700+ mb. when you play them on your laptop they take up the whole screen. with coreplayer, i guess it fits itself in the screen as well.
part of that post i mentioned (the one where i got the settings) also had an attachment that you can use. it's an avi converter which optimizes a present dvd rip (avi) to fit best in a pda screen. i'll see if i can find that thread.
cheers

Robson said:
not sure, but these are avi files that i downloaded straight from the internet. average size is around 700+ mb. when you play them on your laptop they take up the whole screen. with coreplayer, i guess it fits itself in the screen as well.
part of that post i mentioned (the one where i got the settings) also had an attachment that you can use. it's an avi converter which optimizes a present dvd rip (avi) to fit best in a pda screen. i'll see if i can find that thread.
cheers
Click to expand...
Click to collapse
Thanks. Will definately try that.
Is this what you mean?

right on the money, that's the one =)
cheers

Not sure if you guys are aware but new video player released on market that adds lot of new codecs with hardware support this is great for my Nexus S
I know SGS2 pretty much supports most codecs but i dont think it supports DTS this player will play your MKV moves with DTS with full hardware support.
Not software like rockplayer, mobo..ect
Its a paid app but has 3 day trial version
https://market.android.com/details?id=com.inisoft.mediaplayer.trial

The native player supports DTS.
Sent from my GT-I9100 using Tapatalk

Not with the DTS MKV I just tried.

Hmmm, that's strange. I d/l the second dts mkv now, same, it plays flawlessly WITH audio.

now I no my android player better than any other bit of software on android, I have tried every player and know when I see a decent player, this one is pretty decent.
I have a test video I have kept on my phone for 12 months now, a full high profile 1080p copy of a band of brothers episode. Prior to the SG2 nothing I played it on could handle it my HD2, Ipad or Ipad2. When I first got my Sg2 i found that most of the players (that played MKV) would play it but most without sound. Those with sound played it fairly well but if you tried to skip through the film things would go awry.
This player takes a few seconds to skip but it get there and plays in sync - awesome. now this v1.0, looking forward to some more optimisations, this is now my #1 video player, better than rock, mobo, act1, vitl, vplayer and others.
good find, have a thankyou from me.

How peculiar - just tried another video with DTS audio and once again, no sound.

stoolzo said:
this is now my #1 video player, better than rock, mobo, act1, vitl, vplayer and others.
good find, have a thankyou from me.
Click to expand...
Click to collapse
Yup this is the only player so far that actually plays video/audio even when not supported by native OS with actual HArdware support.
Rock player Mobo and every other video player will only play what the OS supports with hardware. So if you dont have DTS support native those players will only play those files with software and play back will be sloppy and quality wont be as good
now with this it will play perfect..with hardware support.
David Horn said:
How peculiar - just tried another video with DTS audio and once again, no sound.
Click to expand...
Click to collapse
not sure ...Ive tested a few and works fine

David Horn said:
How peculiar - just tried another video with DTS audio and once again, no sound.
Click to expand...
Click to collapse
can you provide a link anywhere to this video or upload a small snippet somewhere, perhaps use gspot and post the codecs used?
Dice is chomping through everything I throw at it.

Dice is cool, but can't say it is playing really flawlessly, for example, on a 720p mkv Band of Brother ep02, you can see slight but noticeable stutters, though then again, it indeed is the only player that can play out video/audio in sync while all others failed...

mi3x said:
Hmmm, that's strange. I d/l the second dts mkv now, same, it plays flawlessly WITH audio.
Click to expand...
Click to collapse
are you sure that it is DTS and not AC3??? I tried 2 different mkv-files with DTS audio and could not get any sound... DicePlayer is working, but lags too much... Any other solutions?!

I was checking a 1080p/6ch DTS (1.5 MBit) mkv clip before and while Diceplayer (1.1.1) does play the audio right, it stutters the video like every 2 seconds, unusable.
Rockplayer decodes the 6ch audio in software mode, but the video is superlaggy.
Mobo is superslow and without sound.
Video is playing smoothly in system player... without sound.
I have two apps that decode the audio properly and with little CPU usage (DICE and Rockplayer), and one that decodes video properly and with little CPU usage (System). Unfortunately, it's either or.
Kinda sucks...

Tried my Inception 1080p DTS sample that plays smooth without audio in the stock Video player. It plays with audio in DicePlayer but stutters like mad and is not watchable.

there be be an issue with the way it has been encoded, then again it cannot have a high bitrate as that would make the file over 4 gig and you wouldnt be able to play that due to the FAT32 limit on file sizes. Perhaps you could share the file size, bit rate and codec information of the file you are playing.
If it plays well on the standard player it will likely be H264 mp4, could be main or high profile.

stoolzo said:
there be be an issue with the way it has been encoded, then again it cannot have a high bitrate as that would make the file over 4 gig and you wouldnt be able to play that due to the FAT32 limit on file sizes. Perhaps you could share the file size, bit rate and codec information of the file you are playing.
If it plays well on the standard player it will likely be H264 mp4, could be main or high profile.
Click to expand...
Click to collapse
There's no issue with the encoding as it plays fine on my media center and computer. The full movie is of course well over the FAT limit, but that shouldn't matter for the sample, right. It's a 1080p MKV [email protected]
Here's the mkvinfo output of the sample file:
Code:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 90069522
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4044)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.0.0 + libmatroska v1.0.0
| + Writing application: mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
| + Duration: 61.604s (00:01:01.604)
| + Date: Mon Nov 22 20:44:54 2010 UTC
| + Segment UID: 0xbc 0xee 0x26 0x58 0x42 0x96 0x31 0x6b 0xb9 0x0c 0x7b 0x5f 0x16 0x6d 0xc2 0x59
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 40 (h.264 profile: High @L4.0)
| + Default duration: 41.708ms (23.976 fps for a video track)
| + Video track
| + Pixel width: 1920
| + Pixel height: 800
| + Display width: 1920
| + Display height: 800
| + Content encodings
| + Content encoding
| + Content compression
| + Algorithm: 3 (header removal)
| + Settings: length 1, data: 0x00
| + A track
| + Track number: 2
| + Track UID: 2917809285
| + Track type: audio
| + Codec ID: A_DTS
| + Audio track
| + Sampling frequency: 48000
| + Channels: 6
| + Content encodings
| + Content encoding
| + Content compression
| + Algorithm: 3 (header removal)
| + Settings: length 4, data: 0x7f 0xfe 0x80 0x01
|+ EbmlVoid (size: 1123)
|+ Cluster

720p [email protected] w/AC3 audio plays perfectly fine in the stock player by the way.

I see you have cropped the video but that shouldnt make any difference, to be honest though if it plays on your stock I see nothing to worry about, I have several video players installed, I always check stock, then dice then rock to see which it plays best on. Stock is actually pretty good and has half decent codec support I find.

i agree with stoolzo. there is 4g limit on android devices. player is not my best partner. any player is not perfect. but i perfer to standard player. when video formats don't play on my phone, convert it. it is so easy.

alexcarterkarsus said:
Dice is cool, but can't say it is playing really flawlessly, for example, on a 720p mkv Band of Brother ep02, you can see slight but noticeable stutters, though then again, it indeed is the only player that can play out video/audio in sync while all others failed...
Click to expand...
Click to collapse
try diceplayer 1.1.6 ( not free ).
it play 1080p Band of Brothers ep02 with almost no shutter.
1080p Kill.Bill Sample clip test video
http://www.youtube.com/watch?v=ANf4oCNSxn0

just download a mkv dts video to play on diceplayer 1.1.2, video play good but no sound. what do i? need to download latest diceplayer or not? help plz?

Ok, so I split a movie in parts <4GB using mkvmerge (faster than recompress) and put it on the sd card. I also copied one part to internal mem to exclude the"slow sd" factor. Dice plays a bit choppy from both. However, the cpu never goes higher than about 40% when decoding. (goes for both Dice and stock players btw)
So as it's probably not a bandwidth or cpu bottleneck, what can it be?
Sent from my GT-I9100 using XDA Premium App

I am trying to play flac files (16 bit, 44.1 khz) on neutron audio player with bit perfect playback but the Note 3 automatically resamples to 48 khz. Is their any settings I can mod to make the phone sample to 44.1 khz like some older phones do (ie. Galaxy Nexus).

When I record a video on my G6 (from T-mobile) and set the video resolution to FHD 16:9 60fps, the resulting MP4 video files have an incorrect frame rate. I see 59.51fps, instead of the expected 60.00 or 59.94. The result of this is that any video that's more than a few seconds long has audio/video getting out of sync, and the de-sync gets worse further into the video.
Here is the (trimmed) output from the ffprobe utility (from the ffmpeg project):
Code:
> ffprobe take1.mp4
ffprobe version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2007-2017 the FFmpeg developers
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'take1.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
creation_time : 2017-10-22 01:04:08
location : [redacted]
location-eng : [redacted]
Duration: 00:02:43.91, start: 0.000000, bitrate: 24154 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/smpte170m), 1920x1080, 23980 kb/s, SAR 1:1 DAR 16:9, 59.51 fps, 90k tbr, 90k tbn, 180k tbc (default)
Metadata:
creation_time : 2017-10-22 01:04:08
handler_name : VideoHandle
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 155 kb/s (default)
Metadata:
creation_time : 2017-10-22 01:04:08
handler_name : SoundHandle
I was able to fix the time stamps (PTSs) using the mkvmerge utility, but that isn't the best solution. This does seem like an actual bug. Here's hoping that anyone from LG's engineering team checks this subreddit!

Hi may I ask a question
Can anyone give me your output of adb shell dumpsys media.audio_flinger for DSD64 Stereo playing via stock lg music app?
I am getting:
Output thread 0xf1061000 type 1 (DIRECT):
Thread name: AudioOut_2BD
I/O handle: 701
TID: 8763
Standby: no
Sample rate: 88200 Hz
HAL frame count: 3552
HAL format: 0x6 (pcm24)
Here is the DSD64 Stereo sample I used:
https://www.oppodigital.com/hra/dsd-by-davidelias.aspx