In any case, it does seem to be unfolding MQA with the in-app purchase active. Note the important parts of 2L38_01 that your dog was previously missing:
Sorry that I missed your request ..I think I've narrowed down the behavior that causes these PCM playback problems with Android Pie. @ctheanh - would you be willing to run a small test for me?
Try this in either UAPP, Neutron or the LG Music app.
1) Kill all other music apps (clear them from the notification shade too) and reboot.
2) Start playing a 44 kHz PCM file. Confirm you have the correct (44 kHz, 24-bit) sample rate via DIRECT mode output in audio_flinger.
3) Without hitting pause, immediately start to play any other PCM file with a higher sample rate (e.g., 96/24 or 192/24).
I'm seeing this consistently cause a re-sampling to 48 kHz via the MIXER.
If you remember to hit pause in between changing tracks to different sample rates, you should be able to maintain DIRECT mode output.
But any time you try to instantly switch sample rates to a hi-res PCM, the log is complaining the quad DAC is in use and it ends up getting piped through the MIXER
This is not an issue in Android 8 in any music app.
I'd love to know if you can consistently reproduce the behavior I'm seeing.
P.S. One edit to the above. If you use the LG music app for this test, it obviously won't play back 44 kHz PCM via DIRECT mode. In that case, try switching between, say 96/24 and 192/24 PCM.
P.P.S. I think the reason why Poweramp is working consistently on Android Pie is pure pot luck and nothing to do with brilliance on the part of the Poweramp dev. Poweramp forces you to set a sample rate (I've just left mine at 96 kHz), so, obviously, the sample rate isn't ever changing when you switch tracks.
Now I understand MQA may only be using 13 of 16 bits up to 44 kHz, so 6.03*13 ~ 78 dB and maybe this explains why low-amplitude, high frequency content is being lost? But then what's the point of MQA, because surely most/all very high frequency content is inevitably going to be of low amplitude? BTW, this isn't a problem unique to Android Pie, because I see the exact same thing with Oreo: To elaborate on some concerns from my first rant on MQA (on page 1), I'm really surprised MQA has gained this much traction. MQA files are certainly a good thing for LG phone users, but only (or 99.9%) because of the fact that they're 24 bit files and so play back without re-sampling on these phones' DACs.here is an article about MQA if you interested http://www.iar-80.com/page170.htmlHere are some more thoughts on the MQA situation. Firstly, an explanation of what I'm doing so that others can reproduce and confirm this (or confirm that I'm an idiot that's overlooked something blindingly obvious...). I recorded (at 96 kHz, 24-bit) [3:35] seconds of the left channel from the Mozart Violin concerto in D major - Allegro Marianne Thorsen / TrondheimSolistene: http://www.2l.no/hires/ . You can see my FFT settings in the plots. All amplitudes were adjusted in software so that all tracks were -1 dBFS.
Firstly, here's the original file:
Here's UAPP playing back the original 96 kHz track. Looks basically identical:
Here's LG's MQA decoder running in Android Pie on a V40:
It's clearly missing something
Interestingly, UAPP's in-app purchased SW decoder seems to do a tiny bit better:
A couple of nuances to point out here. If you have the latest Play Store version of UAPP, you can't disable LG's MQA decoder (I've referred to this above as hardware decoder, but somewhere along the line of course, it's all software, and debates have raged about exactly where that decoding takes place. Just bear with me for the purposes of labelling!) I'm currently working with a beta version of UAPP in which I can toggle between the SW (in-app purchase) and HW MQA decoders.
For both software and hardware (or LG's software) MQA decoder, you need to have bit perfect mode set to "on" under "Internal HiRes Audio" settings. Also, under "HiRes driver flags", MQA obviously has to be on for LG's hardware MQA decoder. (That flag is irrelevant/not used if you'd previously paid for the in app purchase. With the latest Play Store version of UAPP, the paid/in-app software decoder wouldn't be used anymore, even if you turned this MQA flag off.)
One other little nuance - with the in-app purchase, you'd see a little blue dot on the now-playing screen when playing MQA with the software decoder active. UAPP doesn't do that using the built-in API flags to force use of the hardware decoder, because there's no way (at least that Davy currently knows of) for UAPP to query the internal state of the DAC. So you lose the blue dot on the now-playing screen. That's expected behavior and nothing to worry about.
In summary, it looks like UAPP is doing everything right in the sense that it is reproducing what LG/Meridian/MQA intend from an MQA track. That being said, I'm not quite sure why differences from the original hi-res file are this noticeable. Perhaps I'd just not looked closely-enough before?
Exactly. Wouldn't you?! I'm afraid none of this has convinced me that paying for MQA isn't like hiring somebody to rob you
At heart, MQA is an attempt to lock down all aspects of audio playback by a business entity that owns both the encoding and decoding chain, and extracts patent license revenues at every step. MQA-file playback gives you degraded performance if you play that content on a device that doesn't support MQA - in fact, on non MQA DACs, MQA playback may not be as good as even the original 44 kHz PCM because of the loss of some of those bits. It also effectively prevents the use of some basic DSP functionality like EQ, mixing multiple sources, digital room correction, advanced digital filters, e.g., crossover and spatial processing. It's alleged by Rob Watts that the short filters in MQA cause audible digital aliasing that has negative consequences for sound. (I've not yet seen any push-back from MQA on those claims.) It's unlikely Chord is ever going to play along (and pay along) with MQA. There are numerous patents for adding hard DRM to MQA. Just the fact that it's a proprietary format should be enough of a red flag, but MQA shields itself from criticism by hiding any opportunity to compare it honestly to FLAC (MQA have repeatedly dodged requests for an MQA-encoded hi-res sine sweep).
It's all a bit odd in this (almost) age of 5G networks and the ability to download HD, multi-Gb movies in seconds. Why do we need to take these lossy short cuts on Mb audio tracks?
Ok, that was a long-winded way of saying I don't know what's going on with MQA and I don't understand why it can't perfectly reproduce 96 kHz PCM (as Bob Steward once told me to my face it could) and I'm afraid I don't care enough about MQA to keep writing posts about it. If anybody else would like to try and reproduce what I've done with these digital recordings, feel free to reach out. If you're just a consumer of MQA, you can relax(?) in the knowledge that MQA playback via UAPP at least isn't doing anything different than what you'd get from LG's own music app.
P.S. I made the suggestion to Davy that he create an option in a future version of UAPP to allow users to choose between the sofware/in-app purchased UAPP decoder and the LG hardware decoder. We'll see what transpires there...
Here are some more thoughts on the MQA situation. Firstly, an explanation of what I'm doing so that others can reproduce and confirm this (or confirm that I'm an idiot that's overlooked something blindingly obvious...). I recorded (at 96 kHz, 24-bit) [3:35] seconds of the left channel from the Mozart Violin concerto in D major - Allegro Marianne Thorsen / TrondheimSolistene: http://www.2l.no/hires/ . You can see my FFT settings in the plots. All amplitudes were adjusted in software so that all tracks were -1 dBFS.
Firstly, here's the original file:
Here's UAPP playing back the original 96 kHz track. Looks basically identical:
Here's LG's MQA decoder running in Android Pie on a V40:
It's clearly missing something
Interestingly, UAPP's in-app purchased SW decoder seems to do a tiny bit better:
A couple of nuances to point out here. If you have the latest Play Store version of UAPP, you can't disable LG's MQA decoder (I've referred to this above as hardware decoder, but somewhere along the line of course, it's all software, and debates have raged about exactly where that decoding takes place. Just bear with me for the purposes of labelling!) I'm currently working with a beta version of UAPP in which I can toggle between the SW (in-app purchase) and HW MQA decoders.
For both software and hardware (or LG's software) MQA decoder, you need to have bit perfect mode set to "on" under "Internal HiRes Audio" settings. Also, under "HiRes driver flags", MQA obviously has to be on for LG's hardware MQA decoder. (That flag is irrelevant/not used if you'd previously paid for the in app purchase. With the latest Play Store version of UAPP, the paid/in-app software decoder wouldn't be used anymore, even if you turned this MQA flag off.)
One other little nuance - with the in-app purchase, you'd see a little blue dot on the now-playing screen when playing MQA with the software decoder active. UAPP doesn't do that using the built-in API flags to force use of the hardware decoder, because there's no way (at least that Davy currently knows of) for UAPP to query the internal state of the DAC. So you lose the blue dot on the now-playing screen. That's expected behavior and nothing to worry about.
In summary, it looks like UAPP is doing everything right in the sense that it is reproducing what LG/Meridian/MQA intend from an MQA track. That being said, I'm not quite sure why differences from the original hi-res file are this noticeable. Perhaps I'd just not looked closely-enough before?
Exactly. Wouldn't you?! I'm afraid none of this has convinced me that paying for MQA isn't like hiring somebody to rob you
At heart, MQA is an attempt to lock down all aspects of audio playback by a business entity that owns both the encoding and decoding chain, and extracts patent license revenues at every step. MQA-file playback gives you degraded performance if you play that content on a device that doesn't support MQA - in fact, on non MQA DACs, MQA playback may not be as good as even the original 44 kHz PCM because of the loss of some of those bits. It also effectively prevents the use of some basic DSP functionality like EQ, mixing multiple sources, digital room correction, advanced digital filters, e.g., crossover and spatial processing. It's alleged by Rob Watts that the short filters in MQA cause audible digital aliasing that has negative consequences for sound. (I've not yet seen any push-back from MQA on those claims.) It's unlikely Chord is ever going to play along (and pay along) with MQA. There are numerous patents for adding hard DRM to MQA. Just the fact that it's a proprietary format should be enough of a red flag, but MQA shields itself from criticism by hiding any opportunity to compare it honestly to FLAC (MQA have repeatedly dodged requests for an MQA-encoded hi-res sine sweep).
It's all a bit odd in this (almost) age of 5G networks and the ability to download HD, multi-Gb movies in seconds. Why do we need to take these lossy short cuts on Mb audio tracks?
Ok, that was a long-winded way of saying I don't know what's going on with MQA and I don't understand why it can't perfectly reproduce 96 kHz PCM (as Bob Steward once told me to my face it could) and I'm afraid I don't care enough about MQA to keep writing posts about it. If anybody else would like to try and reproduce what I've done with these digital recordings, feel free to reach out. If you're just a consumer of MQA, you can relax(?) in the knowledge that MQA playback via UAPP at least isn't doing anything different than what you'd get from LG's own music app.
P.S. I made the suggestion to Davy that he create an option in a future version of UAPP to allow users to choose between the sofware/in-app purchased UAPP decoder and the LG hardware decoder. We'll see what transpires there...
