Has anyone seen a problem with playing AVI movies? I have tried like 3 different video players (RockPlayer, Mobo, Vplayer Pro) and they all play fine for like 20-30 seconds and playback stops. I've tried this with a few movies and they all seem to do the same thing.
I can't figure out why it does this?
Anyone else seeing the same thing?
Here is some of the logcat output that is shown when the video stops playing with MoboPlayer:
Code:
D/WifiService( 112): acquireWifiLockLocked: WifiLock{NetworkLocationProvider ty
pe=2 [email protected]}
I/System.out( 240): [INFO:388216]: LogSource: Running flush
I/System.out( 240): [INFO:388217]: LogSource: Sending payload [bytes=575]
I/System.out( 240): [INFO:388412]: LogSource: Response [http=200,length=265]
I/System.out( 240): [INFO:388413]: LogSource: Read id 8, status code 200
I/ActivityManager( 112): Starting: Intent { flg=0x10000000 cmp=com.google.andro
id.apps.maps/com.google.googlenav.login.AndroidLoginActivitySdk5 (has extras) }
from pid 847
D/SurfaceFlinger( 112): screenshot: sw=216, sh=135, minZ=0, maxZ=21040
D/SurfaceFlinger( 112): screenshot: result = OK
V/AudioFlinger( 82): pause(4097), calling thread 825
V/AudioFlinger( 82): ACTIVE/RESUMING => PAUSING (4097) on thread 0x37540
D/player ( 825): onPause
V/mytag ( 825): ScanFileActivity OnResult
V/item ( 825): read success!
V/item ( 825): write success!
W/Resources( 825): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f0b00
03}
W/Resources( 825): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f0b00
1d}
W/Resources( 825): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f0b00
03}
W/Resources( 825): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f0b00
1d}
W/Resources( 825): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f0b00
03}
W/Resources( 825): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f0b00
1d}
D/dalvikvm( 184): GC_EXPLICIT freed <1K, 31% free 7121K/10311K, paused 2ms+1ms
D/player ( 825): onStop
D/player ( 825): onDestroy
W/ActivityManager( 112): Duplicate finish request for ActivityRecord{41cb8ab0 c
om.clov4r.android.nil/.CMPlayer}
V/AudioFlinger( 82): remove track (4097) and delete from mixer
V/AudioFlinger( 82): PlaybackThread::Track destructor
V/AudioFlinger( 82): removeClient_l() pid 825, tid 108, calling tid 82
D/WifiService( 112): releaseWifiLockLocked: WifiLock{NetworkLocationProvider ty
pe=2 [email protected]}
V/AudioFlinger( 82): Audio hardware entering standby, mixer 0x37540, mSuspende
d 0
V/AudioFlinger( 82): MixerThread 0x37540 TID 107 going to sleep
The output of logcat with Rockplayer looks a bit different as it scrolls the logs as such:
Code:
D/dalvikvm( 847): GC_EXPLICIT freed 320K, 7% free 7162K/7687K, paused 2ms+2ms
D/dalvikvm( 656): GC_EXPLICIT freed 388K, 13% free 6658K/7623K, paused 4ms+1ms
D/WifiService( 112): acquireWifiLockLocked: WifiLock{NetworkLocationProvider ty
pe=2 [email protected]}
D/WifiService( 112): releaseWifiLockLocked: WifiLock{NetworkLocationProvider ty
pe=2 [email protected]}
D/SurfaceFlinger( 112): screenshot: sw=216, sh=135, minZ=0, maxZ=21050
I/ActivityManager( 112): Starting: Intent { flg=0x10000000 cmp=com.google.andro
id.apps.maps/com.google.googlenav.login.AndroidLoginActivitySdk5 (has extras) }
from pid 847
D/SurfaceFlinger( 112): screenshot: result = OK
D/RockPlayer( 948): onPause
W/InputManagerService( 112): Window already focused, ignoring focus gain of: co
[email protected]
V/AudioFlinger( 82): getNextBuffer() no more data for track 4097 on thread 0x3
7540
V/AudioFlinger( 82): BUFFER TIMEOUT: remove(4097) from active list on thread 0
x37540
W/AudioTrack( 948): obtainBuffer() track 0x1fed30 disabled, restarting
V/AudioFlinger( 82): start(4097), calling thread 948 session 11
V/AudioFlinger( 82): ? => ACTIVE (4097) on thread 0xaa220
V/AudioFlinger( 82): mWaitWorkCV.broadcast
V/AudioFlinger( 82): BUFFER TIMEOUT: remove(4097) from active list on thread 0
x37540
W/AudioTrack( 948): obtainBuffer() track 0x1fed30 disabled, restarting
V/AudioFlinger( 82): start(4097), calling thread 948 session 11
V/AudioFlinger( 82): ? => ACTIVE (4097) on thread 0xaa220
V/AudioFlinger( 82): mWaitWorkCV.broadcast
V/AudioFlinger( 82): BUFFER TIMEOUT: remove(4097) from active list on thread 0
x37540
W/AudioTrack( 948): obtainBuffer() track 0x1fed30 disabled, restarting
V/AudioFlinger( 82): start(4097), calling thread 948 session 11
V/AudioFlinger( 82): ? => ACTIVE (4097) on thread 0xaa220
V/AudioFlinger( 82): mWaitWorkCV.broadcast
V/AudioFlinger( 82): BUFFER TIMEOUT: remove(4097) from active list on thread 0
x37540
No problems with moboplayer, I get some random FC with VitalPlayer
maybe you can post a media info about your avi file?
I did a wipe and now I'm no longer having the issue.
What kind of wipe? System wipe????
I have watched 5 movies formatted in avi on my a500 using the preloaded nemoplayer and rockplayer.....
Sent from my XT720 using XDA App
I had avi playing fine at first. I then did a little rooting, got it set up for ad-hoc support and then got netflix running. Now when i try and play avi files, it tells me it cannot play the file. Tried the novo and the built in video player. did the netflix hack break something?
P.S. i am sorry i am little new to this. so go easy on me lol
yeah mobo player is not as good as everyone says it is. why don't you give it a try to mx player. they have a free version just like mobo and i found their playback to be much less troublesome and greater format support than mobo.
+1 to the post above mine
Rockplayer and Moboplayer and diceplayer have never worked nearly as well as Mx player (at least in my experience). It is totally free, and has hardware decoding as well as two modes of software decoding available. In my experience, it plays everything I have thrown at it.
Is there any new news about playing 720p and 1080p video files on this tablet ?
This is very important for me to make a decision for buying it.
Mourningdark said:
I had avi playing fine at first. I then did a little rooting, got it set up for ad-hoc support and then got netflix running. Now when i try and play avi files, it tells me it cannot play the file. Tried the novo and the built in video player. did the netflix hack break something?
P.S. i am sorry i am little new to this. so go easy on me lol
Click to expand...
Click to collapse
After I hacked the moto libdv??.so file into my system/lib my video and mp3 stopped working... If I copy the original back it all works again... wish there was a way to play netflix without breaking everything =(
[email protected] said:
yeah mobo player is not as good as everyone says it is. why don't you give it a try to mx player. they have a free version just like mobo and i found their playback to be much less troublesome and greater format support than mobo.
Click to expand...
Click to collapse
Only problem with mx is that you have to tell the program where your video files are. I have a 1tb drive that I use with my acer and when I tell mx to use it it takes forever to load every single video file in my 1tb into a single folder... I much prefer mobo's file browser approach!! Some of my divx avi's didn't play on mx... they all play on mobo (in soft decode mode)
Would you please somebody help me to find out how plays the following video formats on Iconia A500 :
720P - MKV - more than 4Gb ?
720P - MKV - Under 4 Gb ?
720p - MP4 ?
720p - Avi ?
And other video formats .
mehdi-psp said:
Would you please somebody help me to find out how plays the following video formats on Iconia A500 :
720P - MKV - more than 4Gb ?
720P - MKV - Under 4 Gb ?
720p - MP4 ?
720p - Avi ?
And other video formats .
Click to expand...
Click to collapse
It all depends on the codecs used. MKV, MP4, AVI, etc are just containers multiplexing the video, audio and subtitle streams. For example I can play an 720p avi fine wth mx player and can't play a 480p avi (both play fine on my laptop with vlc). Anyway if you decide to reencode, I found out that setting the desired file size to 1gb and using 2-pass x264 codecs for the video and 128 kbps aac (mp4 file of course) for the audio gives satisfactory results. Video quality could be bit better but on the other hand I'd prefer to have more videos on it. Reencoding takes quite a while, but since I got the iconia I rarely use my laptop, so it sits quietly in the corner and utilizes it's quad-core cpu
Sent from my A500 using XDA Premium App
tkolev said:
It all depends on the codecs used. MKV, MP4, AVI, etc are just containers multiplexing the video, audio and subtitle streams. For example I can play an 720p avi fine wth mx player and can't play a 480p avi (both play fine on my laptop with vlc). Anyway if you decide to reencode, I found out that setting the desired file size to 1gb and using 2-pass x264 codecs for the video and 128 kbps aac (mp4 file of course) for the audio gives satisfactory results. Video quality could be bit better but on the other hand I'd prefer to have more videos on it. Reencoding takes quite a while, but since I got the iconia I rarely use my laptop, so it sits quietly in the corner and utilizes it's quad-core cpu
Sent from my A500 using XDA Premium App
Click to expand...
Click to collapse
Thanks for your explanation , Actually I want to use Iconia A500 as a video payer not any more .
As a matter of fact and with regard to your explanation it will not be usefull for playing video file .
Since a large number of my video files are 1280 * 720 or 1280 * 544 with high bit rate in both audio and video I think I have to change my mind for buying Iconia A500 . Am I right ?
so far, i have used the oem players and they dont work for the movies i am trying to load. i.e.: mp4, avi....etc i downloaded mx player and boom. im in business. this is why i like xda and have been here like flies on s**t......lol
mehdi-psp said:
Is there any new news about playing 720p and 1080p video files on this tablet ?
This is very important for me to make a decision for buying it.
Click to expand...
Click to collapse
No tablet currently can play 1080p natively, as no tablet has a resolution of 1080p or higher. IIRC the next Gen Samsung tabs will have a native resolution higher than 1080p.
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.