Related
My code is fairly simple:
Code:
ar = new AudioRecord(AudioSource.MIC,44100,AudioFormat.CHANNEL_IN_STEREO,AudioFormat.ENCODING_PCM_16BIT,16640);
Debug on my Galaxy Tab P1000 outputs:
12-10 15:07:41.331: INFO/AudioHardwareALSA(2395): AudioStreamInALSA - input - format = 1, channels = 12, rate = 44100
12-10 15:07:41.331: INFO/AudioHardwareALSA(2395): AudioStreamInALSA - default - format = 1, channels = 16, rate = 44100
12-10 15:07:41.331: INFO/AudioHardwareALSA(2395): AudioStreamInALSA - input - format = 1, channels = 16, rate = 44100
12-10 15:07:41.331: INFO/AudioHardwareALSA(2395): AudioStreamInALSA - default - format = 1, channels = 16, rate = 44100
12-10 15:07:41.331: ERROR/ALSALib(2395): external/alsa-lib/src/pcm/pcm.c:2201snd_pcm_open_noupdate) Unknown PCM AndroidRecord_Speaker
12-10 15:07:41.335: ERROR/ALSALib(2395): external/alsa-lib/src/pcm/pcm.c:2201snd_pcm_open_noupdate) Unknown PCM NULL_Device
12-10 15:07:41.335: INFO/AudioHardwareALSA(2395): Initialized ALSA CAPTURE device NULL_Device
12-10 15:07:41.335: ERROR/AudioHardwareALSA(2395): open (0,0x40000) = -2
12-10 15:07:41.335: ERROR/AudioHardwareALSA(2395): setInputDevice(0 , 0x40000) = -2
12-10 15:07:41.335: ERROR/AudioRecord(3980): Could not get audio input for record source 1
12-10 15:07:41.335: ERROR/AudioRecord-JNI(3980): Error creating AudioRecord instance: initialization check failed.
12-10 15:07:41.335: ERROR/AudioRecord-Java(3980): [ android.media.AudioRecord ] Error code -20 when initializing native AudioRecord object.
I tried various AudioSources, SampleRates, Channels, Encodings, BufferSizes, but it always stops with these errors.
It seems to me that the AudioSource is not transmitted correctly. The tab's "asound.conf" has no "AndroidRecord_Speaker" though it does have an "AndroidRecord_Microphone" which apparantly cannot be accessed by the AudioRecord constructor.
Someone knows at which point the AudioSource ENUM is mapped to the devices in asound.conf?
Or what else might be going wrong?
Hey _nop_!
Posting here as haven't posted enough to be able to post in Android Dev
Had a go testing it, with some somewhat strange results
Firstly, when plugged in to HDMI the touch screen goes a bit crazy! It seems to jitter about the place and do some crazy movements that I'm not doing with my finger - will try to get a video to show it better.
Secondly, the tool seems to sometimes say 'HDMI Connected' and sometimes 'HDMI disconnected' - I can't tell the right sequence to get it to say connected. When it does say connected though hitting HDMI on doesn't seem to do anything. Have attached a log cat that will hopefully help a bit more..
Hi and thank you!
Touch can behave this way due to interference from hdmi cable.
Next, would you try playing native videostream from third-party app like QuickPic with HDMI on?
And hdmi judging from log was successfully enabled:
E/PrintK ( 4): == VendorProductId == E/PrintK ( 4): <3>[EDID Info] edid->vpi->manuf=SNY E/PrintK ( 4): <3>[EDID Info] edid->vpi->prodcode=0 211 1 E/PrintK ( 4): <3>[EDID Info] edid->vpi->serial=257 257 E/PrintK ( 4): <3>[EDID Info] edid->vpi->week=1 E/PrintK ( 4): <3>[EDID Info] edid->vpi->year=2009 E/PrintK ( 4): <3>[EDID Info] edid->mdb->mon_name=SONY TV E/PrintK ( 4): <3>[EDID Info] edid->cea->cea->vsdb_hdmi=1 E/PrintK ( 4): <3>[EDID Info] ################################ E/PrintK ( 4): <3>[EDID Info] next_segment_number=0 E/PrintK ( 4): <3>[EDID Info] no more next_segment_number[0], we disable EDID_INT here!! E/PrintK ( 4): <3>next_segment=0x0 E/PrintK ( 4): <3>### action 7 ### E/PrintK ( 4): next segment is 0 E/PrintK ( 4): <3>HDMI Tx Presets Loaded E/PrintK ( 4): <3> E/PrintK ( 4): Cable Connected E/PrintK ( 4): <3> E/PrintK ( 4): DVI Supported Video Format = 0xf0 E/PrintK ( 4): <3>Supported Video Format: 720p E/PrintK ( 4): <3>Supported Video Format: 1080i E/PrintK ( 4): <3>PCLK lock=1
It's a Sony At least some success.
Now to figure out how to output something to hdmi manually...
Would you run this command in term. emulator with su:
while [ 1 == 1 ]; do cp /dev/graphics/fb0 /dev/graphics/fb1; usleep 100000; done;
(ctrl-c to break, I map vol. up as ctrl in terminal emulator).
What do you mean by native videostream? I tried a few different videos but nothing came up on screen. Is anything supposed to come up on the HDMI tool after I hit HDMI On?
Are you on any IRC channels we could talk this through?
I don't use IRC now.
--
Any recorded video by Streak itself should do.
I can't get the HDMI tool to say HDMI Connected now, although you can see from the attached logcat it is noticing the disconnect/connect. What triggers the tool to say HDMI Connected? Also note it seems to switch orientation to profile when disconnected?
I ssh in over the wifi from putty on my laptop - ran up a shell script of your commands provided - no output on screen though..
Another log cat attached - not sure if it's of any help, but it is of a video taken with camera played through hdmi via the stock Gallery app.
Looks like i need to get dock or make a hdmi connector.
Also, hdmi lib contains three quite simple functions:
isHdmiConnected, enableHdmi, disableHdmi
I simply used them to check.
--
I know it's not that simple.
Chip:
http://www.siliconimage.com/products/product.aspx?pid=118
--
Also - check "Send to framebuffer" app - it allows to send pics to framebuffer, i wonder does it work.
Hey,
Tried out that Framebuffer - no image, see attached log.
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
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.