Ever since mm update the bt aptx connection skips/freezes momentarily. I haven't isolated an exact pattern, seems to happen more often in some setups than others. For instance, listening to bt aptx music via Google music play results in often freezes on my both headsets, sennheiser mm400 and telme2. Listening via poweramp however yields less skips but it happens. I am really bothered by this new issue, as I thought, after upgrading to this phone, that I have finally found the perfect bt listening device.
I'd like to know if there's other people affected by this so I can report to Sony, so if you could bother to answer this informal poll, with fw revision, app where this problem occurs and frequency.
Thanks
Sent from my E6653 using Tapatalk
Customized NOBA, 32.1.A.1.163/R10C, Google Music, very often, while screen off or on.
Sent from my E6653 using Tapatalk
Does it happen on stock music player?
gm007 said:
Does it happen on stock music player?
Click to expand...
Click to collapse
It doesn't. But it might be not fully related to bt as I had to copy the flac test file from ext sdcard as stock music player didn't like my external storage configuration. Strangely so, cause I'm almost sure it used to work before. How would you force start media scanner?
Sent from my E6653 using Tapatalk
Not sure about media scanning for music,but for pictures there is in album app a media fix that can scan for all the pictures.
Maybe clear data for music app.
It's not related to storage location, I think. I just realized gm was storing its sh1t on internal sdcard. Just changed that. So the skipping/stuttering happens mostly in google music. It also happens in poweramp and gmmp but less frequently, less skipping and less artifacts too. The Google music skipping mostly occurs when using the phone for other tasks such as navigating Tapatalk or typing here. I dunno what to think of stock music player. Don't tell me Sony won't look at this if only happens in third party apps.
Sent from my E6653 using Tapatalk
Maybe stock music has bigger buffer that's why it's not skipping.
Do power amp or google music has some setting to increase the buffer?
gm007 said:
Maybe stock music has bigger buffer that's why it's not skipping.
Do power amp or google music has some setting to increase the buffer?
Click to expand...
Click to collapse
Not specific to bt. Poweramp has a bt thread priority that haven't tried yet. However, I'm listening Google music wired, same headset as earlier but wired, no issues.
Sent from my E6653 using Tapatalk
Hey there. Thanks for creating this thread. I'm on the very same boat.
Z5 dual here, E6683. I tried 'customized RU' and 'customized HK' but both present the very same problems. I tried many things and it does seem like a CPU bound problem but it's still quite random. Sometimes I can listen to music for a while without problems, but then it will start skipping like crazy and you have to stop it. Wired headsets work fine. It's true that seems to happen more on Google Music for me too, but it's happening also but less often on Tune-in or Spotify.
It has been incredibly frustrating. I use bt audio a lot so this makes my device unusable. Sort of fed up at this moment with Sony. It's march now, 6 months after release, and my device is still not working as it should on release day. MM did fix lots of issues thought, but it sort of feels Sony is in perpetual beta with their flagship device.
Mine was doing the same, and often, reboot fixed it pretty much for me
I had the z5 connected to my car bt, listened to google music on my way home, about 30 minutes, no problem whatsoever. But the car bt is not aptx..I am going to look at logcat tomorrow. Anyways, unless more mm z5 owners come forward with this issue it's hard to convince Sony there's a problem at all. And I didn't even see one mention of this on talk.sonymobile forums.
Sent from my E6653 using Tapatalk
danw_oz said:
Mine was doing the same, and often, reboot fixed it pretty much for me
Click to expand...
Click to collapse
It didn't here. I mean between reboots I'd get smoother streaming for a while, then it's back again to freezing and noise artifacts. I am trying for a while now to find a pattern in this, maybe another app that interferes, something in our setup that causes it. I am close to factory reset and try again, I will take a look at logcat though I don't hope for too much.
Sent from my E6653 using Tapatalk
I use dayli bt audio and I don't have any issue.. (true only stock music player) (android 6.0)
This has been happening with Android for age's you can find threads on this all over the Internet. But it's hit and miss as to what devices it happens with. I'm my car I don't have any problems with bt skip but in the house from my phone to my Arcam rblink it skips and yes is bothers me too I've tried to isolate what app or what ever it may be in the phone but nothing... and like wise surcingles the Web no one seems to have a fix. Well now I'm on MM I can give up thinking a fix might come in this upgrade.... well it didn't.
S6 edge Clear View Cover fix. https://youtu.be/lA6giyj1z7U
Loz
Sent from my SM-G925F using XDA Free mobile app
It worked perfectly for me in lollipop.
Sent from my E6653 using Tapatalk
It's the issue with the 4G, 2.4G, 5G signal that we commonly encounter , they interfere with the ldac and the aptx bt transmission. Furthermore, what I found is that the freezing issue is highly related to the cpu using and the internet using. Turn your phone into flight mode and left only bt open and check again.
I've noticed a skipping/cutting behaviour when listening through bt in my car. No problem whatsoever when on lollipop but now it's terrible. It's actually in a state where I'm forced to use something else as a source.
Obviously, when the only thing that have changed is the OS version it's easy too assume some kind of bug. Worked flawlessly with my z3 and z5 lollipop.
Marshmallow has been a nightmare so far i terms of audio.
hunterfred said:
It's the issue with the 4G, 2.4G, 5G signal that we commonly encounter , they interfere with the ldac and the aptx bt transmission. Furthermore, what I found is that the freezing issue is highly related to the cpu using and the internet using. Turn your phone into flight mode and left only bt open and check again.
Click to expand...
Click to collapse
Flight mode wouldn't work for me as I do a lot of streaming music live.?
S6 edge Clear View Cover fix. https://youtu.be/lA6giyj1z7U
Loz
Sent from my SM-G925F using XDA Free mobile app
hunterfred said:
It's the issue with the 4G, 2.4G, 5G signal that we commonly encounter , they interfere with the ldac and the aptx bt transmission. Furthermore, what I found is that the freezing issue is highly related to the cpu using and the internet using. Turn your phone into flight mode and left only bt open and check again.
Click to expand...
Click to collapse
I tried the airplane mode in spite of being a bit skeptic about this: after listening for half an hour I can conclude airplane mode (with bt on) helps, I didn't experience any significant freeze with google music (in offline mode)
This is a logcat main buffer log from INFO onwards, I logged these line every time I had any kind of freeze: of course I missed some lines and especially didn't put down single 'underrun' lines (occurring only one at a time) that didn't seem to impact that much, ie no freezing/stuttering I could easily tell. More 'underrun' lines, the bigger the gap/freeze. Sometimes I tried to trigger the problem by turning the screen on, etc. As you can see, the issue happens fairly often, at least once in 5 minutes.
I intend to create an entry on talk.sonymobile later today where I will resume our collective experience and invite you all to also add your comments over there.
Code:
03-16 08:48:15.460 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 08:48:15.470 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 08:48:15.485 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
3-16 08:51:25.852 9738 10575 W bt_btif : underrun only read 192 bytes out of 240
03-16 08:51:25.862 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 08:51:25.872 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 08:51:27.803 9738 9959 W bt_hci_packet_fragmenter: reassemble_and_dispatch complete l2cap packet received:l2cap full length 5 and hci length 13.
03-16 08:57:41.825 9738 10575 W bt_btif : underrun only read 80 bytes out of 240
03-16 08:57:41.835 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 08:57:41.845 9738 10575 W bt_btif : underrun only read 0 bytes out of 224
03-16 08:57:41.856 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 08:57:41.870 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:01:16.880 9738 10575 W bt_btif : underrun only read 176 bytes out of 224
03-16 09:01:16.890 9738 10575 W bt_btif : underrun only read 0 bytes out of 224
03-16 09:01:16.901 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:01:39.080 9738 10575 W bt_btif : underrun only read 32 bytes out of 224
03-16 09:02:37.406 9738 9959 W bt_hci_packet_fragmenter: reassemble_and_dispatch complete l2cap packet received:l2cap full length 5 and hci length 13.
03-16 09:02:38.059 1812 2036 I DisplayManagerService: Display device changed state: "Built-in Screen", OFF
03-16 09:02:40.299 1812 3695 I AccountManagerService: getTypesVisibleToCaller: isPermitted? true
03-16 09:02:40.324 3258 4527 I Icing : Performing maintenance.
03-16 09:02:40.385 9738 10575 W bt_btif : underrun only read 112 bytes out of 240
03-16 09:02:40.395 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:02:40.445 1812 3939 E LocSvc_libulp: E/int ulp_brain_transition_all_providers(), no QUIPC/GNSS transition logic run due to both engines are OFF
03-16 09:02:40.483 4704 4704 I GCoreUlr: Starting service, intent=Intent { act=com.google.android.location.reporting.ACTION_UPDATE_ACTIVE_STATE cmp=com.google.android.gms/com.google.android.location.reporting.service.DispatchingService (has extras) }, extras=Bundle[{source=PowerModeReceiver}]
03-16 09:02:40.492 4704 5018 I GCoreUlr: Successfully inserted 1 locations
03-16 09:02:40.494 4704 5018 I GCoreUlr: Cancelling scheduled uploads
03-16 09:02:40.496 4704 5018 I GCoreUlr: Not calling LocationReporter, hasMoved: true, elapsed millis: 298539, request: Moving(600000)
03-16 09:02:40.497 4704 5018 I GCoreUlr: Scheduling next upload for 301461ms from now
03-16 09:02:40.545 4704 5018 I GCoreUlr: DispatchingService.updateActiveState+PowerModeReceiver: Ensuring that reporting is active for [account#8#]
03-16 09:02:40.565 9738 10575 W bt_btif : underrun only read 144 bytes out of 240
03-16 09:02:40.575 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:02:40.586 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:02:40.590 4704 5018 I GCoreUlr: GMS FLP location and AR updates requested: {"description":"default","newRequest":true,"samplePeriodMs":120000,"sampleReason":"default","sampleSource":"internal","timestampMs":1458133360518}
03-16 09:02:40.596 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:02:40.609 4704 5018 I GCoreUlr: Place inference reporting - stopped
03-16 09:02:40.610 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:02:40.624 4704 5018 I GCoreUlr: Cancelling scheduled uploads
03-16 09:02:40.625 9738 10575 W bt_btif : underrun only read 0 bytes out of 240
03-16 09:02:40.625 4704 5018 I GCoreUlr: Not calling LocationReporter, hasMoved: true, elapsed millis: 298669, request: Moving(600000)
03-16 09:02:40.625 4704 5018 I GCoreUlr: Scheduling next upload for 301331ms from now
Related
Hi
Any ideas on how to adjust the a2dp bitpool settings. I am coming from windows mobile where this was easy to do in the registry. The stock bitpool seems to be 32 as per the logcat readout below.
W/BTLD ( 1677): ### :: codec open ::
W/BTLD ( 1677): ### mtu 512, 660 bytes/frame, bitrate 229, nbr ch 0, freq 240
W/BTLD ( 1677): ### alloc : 3, blk len 240, chmode:15, bitpool 32:2, subbands 12
the sound is ok but could be better.
Another interesting part of the logcat is:
V/A2dpAudioInterface( 136): setParameters() bt_headset_name=DRC-BT15;bt_headset_nrec=on
E/AudioHardwareQSD( 136): setParameters() bt_headset_name=DRC-BT15;bt_headset_nrec=on
I/AudioHardwareQSD( 136): Using default acoustic parameters (DRC-BT15 not in acoustic database)
(I wonder what the acoustic database is.)
Any suggestions would be welcome. I did search around and found nothing easily implemented. Also nothing on the market.
Thanks
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.
I recently instaleld Acer_A501_4.066.31_COM_GEN1 on my Australian A501. With this or the 4.066.29 provided by Moscow Desire, I cannot play YouTube videos, neither in the browser or in the YouTube app. The app starts but video will not play. This is with a clean install (cache/system/data wipe). I have tried with 3.5.3, 3.5.4 [stock] and 3.5.5 [latest] YouTube app.
Can provide logcat grabs, but it appears the OMX codec (hardware acceleration) for h264 fails to start on the 3.2.1 ROMs. I had the same problem with some regions of 3.2 rom too.
Any tips appreciated, but for now it's back to 4.483.01 for me (YouTube works fine in this w/ any version of YouTube app).
i had a similar problem. im not sure what browser you are using but in dolphin browser go into the settings and change your display from android to computer i think. and should work.... it will use more data so if your on mobile data you will want to change it back to android to save your data.
galapogos01 said:
I recently instaleld Acer_A501_4.066.31_COM_GEN1 on my Australian A501. With this or the 4.066.29 provided by Moscow Desire, I cannot play YouTube videos, neither in the browser or in the YouTube app. The app starts but video will not play. This is with a clean install (cache/system/data wipe). I have tried with 3.5.3, 3.5.4 [stock] and 3.5.5 [latest] YouTube app.
Can provide logcat grabs, but it appears the OMX codec (hardware acceleration) for h264 fails to start on the 3.2.1 ROMs. I had the same problem with some regions of 3.2 rom too.
Any tips appreciated, but for now it's back to 4.483.01 for me (YouTube works fine in this w/ any version of YouTube app).
Click to expand...
Click to collapse
I'm running 3.2.4, and seems ok here in Moscow. Generally, I don't let any of my apps auto-update, especially the Market App.
So, it's not just youtube. It's anything that tries to use the hardware accelerated h264 codec. MX Video Player in software mode works fine.
There seems to be some issue starting the OMX Codec HW Accel.
Working Logcat
Code:
I/ActivityManager( 135): Displayed com.google.android.youtube/.app.tablet.WatchActivity: +798ms
D/dalvikvm( 1900): GC_CONCURRENT freed 693K, 6% free 21444K/22599K, paused 4ms+4ms
D/YouTube ( 1900): youtube.app.suggest.HistoryDb.query:88 History query returning 0 rows
D/MediaPlayer( 1900): Couldn't open file on client side, trying server side
I/AwesomePlayer( 85): reset
I/AwesomePlayer( 85): cancel player events
I/AwesomePlayer( 85): cancel player events
I/AwesomePlayer( 85): setDataSource_l('http://redirector.c.youtube.com/videoplayback?id=8561f3eee9e535f1&itag=18&source=youtube&uaopt=no-save&el=standard&devKey=ATpxuMO4AN5NR1nGmfaQDBQO88HsQjpE1a8d1GxQnGDm&app=youtube_gdata&ip=0.0.0.0&ipbits=0&expire=1331604646&sparams=id,itag,source,uaopt,ip,ipbits,expire&signature=B58929DFA39322596AF1A07415918502DA795904.ED0E6738CA5428F3A54AD3177B048BF08CE585EF&key=yta1&androidcid=mvapp-android-acer')
D/HAL ( 85): [HAL] hw_get_module:share library path:/system/lib/hw/gralloc.tegra.so
I/NuHTTPDataSource( 85): connect to redirector.c.youtube.com:80/videoplayback?id=8561f3eee9e535f1&itag=18&source=youtube&uaopt=no-save&el=standard&devKey=ATpxuMO4AN5NR1nGmfaQDBQO88HsQjpE1a8d1GxQnGDm&app=youtube_gdata&ip=0.0.0.0&ipbits=0&expire=1331604646&sparams=id,itag,source,uaopt,ip,ipbits,expire&signature=B58929DFA39322596AF1A07415918502DA795904.ED0E6738CA5428F3A54AD3177B048BF08CE585EF&key=yta1&androidcid=mvapp-android-acer @0
I/NuHTTPDataSource( 85): connect to o-o.preferred.eftel-mel1.v11.lscache1.c.youtube.com:80/videoplayback?id=8561f3eee9e535f1&itag=18&source=youtube&uaopt=no-save&el=standard&devKey=ATpxuMO4AN5NR1nGmfaQDBQO88HsQjpE1a8d1GxQnGDm&app=youtube_gdata&ip=0.0.0.0&ipbits=0&expire=1331604646&sparams=id,itag,source,uaopt,ip,ipbits,expire&signature=B58929DFA39322596AF1A07415918502DA795904.ED0E6738CA5428F3A54AD3177B048BF08CE585EF&key=yta1&androidcid=mvapp-android-acer&cms_redirect=yes @0
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] AVC profile = 66 (Baseline), level = 30
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] allocating 10 buffers of size 1566720 on input port
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] allocating 10 buffers from a native window of size 345600 on output port
I/nvos_linux_stub( 85): stub_helper: alloc iovmm
I/nvos_linux_stub( 85): stub_helper: alloc carveout_iram
I/nvos_linux_stub( 85): [email protected]: info=2147483647 DeintType = 2147483647, DeintRate = 2
D/dalvikvm( 907): GC_EXPLICIT freed 145K, 11% free 7049K/7879K, paused 6ms+3ms
D/YouTube ( 1900): youtube.core.player.Tracker.ping:230 Pinging http://video.google.com/s?docid=hWHz7unlNfE&ns=yt&len=11179&el=detailpage&ps=android&rt=6.3&playback=1&plid=cZUZxWkh6DOztSor%0A&av=3203_13&fmt=18
I/AudioService( 135): setCurrentMediaType 2
I/AudioService( 135): setDolbyDefaultEq, MusicEq = 0 , VideoEq = 0
I/AudioService( 135): Current audio device output is Speaker. MediaType=2
I/AudioService( 135): SetNaturalBassOn true
I/AudioService( 135): SetHighFreqEnhancerDepth 0
I/AudioService( 135): SetNaturalBassDepth 0
I/AudioService( 135): setEqSpeaker mediaType= 2, mode= 0
I/nvos_linux_stub( 85): Allocating new output: 640x368 (x 9)
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] allocating 11 buffers from a native window of size 353280 on output port
I/nvos_linux_stub( 85): stub_helper: alloc iovmm
Non-Working Logcat
Code:
I/ActivityManager( 134): Displayed com.google.android.youtube/.app.tablet.WatchActivity: +719ms
D/YouTube ( 3089): youtube.app.suggest.HistoryDb.query:88 History query returning 0 rows
D/MediaPlayer( 3089): Couldn't open file on client side, trying server side
I/AwesomePlayer( 85): reset
I/AwesomePlayer( 85): cancel player events
I/AwesomePlayer( 85): cancel player events
I/AwesomePlayer( 85): setDataSource_l('http://redirector.c.youtube.com/videoplayback?id=8561f3eee9e535f1&itag=18&source=youtube&uaopt=no-save&el=standard&devKey=ATpxuMO4AN5NR1nGmfaQDBQO88HsQjpE1a8d1GxQnGDm&app=youtube_gdata&ip=0.0.0.0&ipbits=0&expire=1331604646&sparams=id,itag,source,uaopt,ip,ipbits,expire&signature=B58929DFA39322596AF1A07415918502DA795904.ED0E6738CA5428F3A54AD3177B048BF08CE585EF&key=yta1&androidcid=mvapp-android-acer')
I/NuHTTPDataSource( 85): connect to redirector.c.youtube.com:80/videoplayback?id=8561f3eee9e535f1&itag=18&source=youtube&uaopt=no-save&el=standard&devKey=ATpxuMO4AN5NR1nGmfaQDBQO88HsQjpE1a8d1GxQnGDm&app=youtube_gdata&ip=0.0.0.0&ipbits=0&expire=1331604646&sparams=id,itag,source,uaopt,ip,ipbits,expire&signature=B58929DFA39322596AF1A07415918502DA795904.ED0E6738CA5428F3A54AD3177B048BF08CE585EF&key=yta1&androidcid=mvapp-android-acer @0
I/NuHTTPDataSource( 85): connect to o-o.preferred.eftel-mel1.v11.lscache1.c.youtube.com:80/videoplayback?id=8561f3eee9e535f1&itag=18&source=youtube&uaopt=no-save&el=standard&devKey=ATpxuMO4AN5NR1nGmfaQDBQO88HsQjpE1a8d1GxQnGDm&app=youtube_gdata&ip=0.0.0.0&ipbits=0&expire=1331604646&sparams=id,itag,source,uaopt,ip,ipbits,expire&signature=B58929DFA39322596AF1A07415918502DA795904.ED0E6738CA5428F3A54AD3177B048BF08CE585EF&key=yta1&androidcid=mvapp-android-acer&cms_redirect=yes @0
D/dalvikvm( 3089): GC_CONCURRENT freed 5906K, 32% free 16291K/23623K, paused 3ms+6ms
I/dalvikvm( 3089): Jit: resizing JitTable from 4096 to 8192
D/dalvikvm( 3089): GC_CONCURRENT freed 1073K, 27% free 17265K/23623K, paused 3ms+5ms
D/dalvikvm( 3089): GC_CONCURRENT freed 849K, 22% free 18463K/23623K, paused 3ms+7ms
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] AVC profile = 66 (Baseline), level = 30
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] allocating 10 buffers of size 1566720 on input port
I/OMXCodec( 85): [OMX.Nvidia.h264.decode] allocating 10 buffers from a native window of size 345600 on output port
I/NuCachedSource2( 85): Keep alive
D/dalvikvm( 2775): GC_EXPLICIT freed 30K, 12% free 14408K/16199K, paused 3ms+37ms
I/ActivityManager( 134): Starting: Intent { cmp=com.google.android.youtube/.app.tablet.WatchActivity (has extras) } from pid 3089
W/Resources( 3089): Converting to string: TypedValue{t=0x12/d=0x0 a=2 r=0x7f08006a}
E/TelephonyManager( 3089): Hidden constructor called more than once per process!
E/TelephonyManager( 3089): Original: com.google.android.youtube, new: com.google.android.youtube
I/AudioService( 134): AudioFocus requestAudioFocus() from [email protected]
D/YouTube ( 3089): youtube.core.async.UserAuthorizer$AuthTokenCallback.run:390 got authToken for [email protected]
I/AudioService( 134): setCurrentMediaType 0
I/AudioService( 134): setDolbyDefaultEq, MusicEq = 0 , VideoEq = 0
I/AudioService( 134): Current audio device output is Speaker. MediaType=0
I/AudioService( 134): SetNaturalBassOn true
I/AudioService( 134): SetHighFreqEnhancerDepth 0
I/AudioService( 134): SetNaturalBassDepth 0
I/AudioService( 134): setEqSpeaker mediaType= 2, mode= 0
I/AwesomePlayer( 85): reset
Can anyone provide a logcat for playing a YouTube video on 3.2.1? Just from the activity creation including any OMX Codec / nvos* entries.
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!
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.