Android and Audio Formats/Sampling Rates

Software
1

I have read in a couple of ‘internet audio places’ that Android takes over all audio streams and up/down converts the sampling rate to 48khz (a video standard of sorts). If this is correct AND I understand what is being said then when I play a hi-res 24 bit/96khz audio file through a Android player, it is being down sampled before being sent to the relevant DAC (Dragonfly Red, for example). And I have no idea what this might mean for a MQA audio stream that looks like a 44.1 - I would think that this upsampling to 48 would tend to mess up all that audio folding that MQA does.

How confused am I here (this time)? Thanks.

dave

2 Likes
2

This doesn’t square with my experience, although I made a big jump from Android 4 (melted Salt Water Taffy on Pleather in the sun) to Android 8 (Crystal Meth Slurpee), at the same time moving from a Motorola XOOM to a generic (CHUWI Hi-Pro 9) phablet.

With the Android 8 Tablet, Tidal reports MQA 44.1 FLAC files typically at 88.2 and 48 KHZ files at 96, which is what you expect. First unfold, can go out through the audio port, OR with an OTG (on the go) cable, you can run it to your Dragonfly or other MQA DAC for the 2nd unfold and the pretty magenta light.

Alternatively, you can use the UAPP application, pay for it’s unfold ability and bypass all the Android specific stuff. If you use the Search here, you’ll find the threads where this is talked about in the MQA Playback section. @Torq is a master here.

2 Likes
3

The standard Android audio-stack resamples to a multiple of 48 kHz by default. It is not, necessarily, downsampling (88.2 kHz material general gets converted to 96 kHz).

This is undesirable for most music content because a) it’s a non-integer (powers of 2) conversion and b) it uses a SINC filter implementation optimized for power consumption rather than precision and exhaustion of the conversion coefficients.

However, individual applications do not have to use the full, default, Android audio-stack - especially for external devices. UAPP, for example, has its own USB UAC2 driver(s) and talks directly to external DACs without going through the default audio-stack.

If an application, say TIDAL, were to use the default Android audio-stack, and do the first MQA unfold, then unless it unfolded to 88.2 kHz, the 96 kHz output from that process does not need to be resampled to be at a multiple of 48 kHz … ergo no changes to the data occur and the MQA content is preserved.

9 Likes
4

Thanks for the comments. Very helpful.

Does anyone know what the Tidal Android desktop app is doing WRT the Android audio stack? It sounds like there is no Android equivalent to “exclusive mode” in Windows 10.

dave

5

As far as I’m aware it is using the default Android audio-stack. Without an external DAC, this means native 16/44.1 kHz content is typically re-sampled to 16/48 kHz or 24/48 kHz prior to being fed to the internal DAC.

For MQA content, the MQA processing (first unfold) occurs in the TIDAL application itself, and the decoded/unfolded sample data is then passed to the Android audio-stack. If the output of that MQA unfolding is at 96 kHz no additional re-sampling occurs (if it was at 88.2 kHz then it’d get up-sampled to 96 kHz) - thus it can drive an external DAC for the 2nd unfold etc.

3 Likes
6

I did a bit more research (to fill in my own knowledge gaps in this space). From my perspective if you are going to be playing anything hi-res through an Android device and have a Tidal Hi-res subscription, then the UAPP product (paid - less than $5) is the way to go.

dave

4 Likes
7

USB Audio Player Pro (UAPP) is a solid way to deal with both local and streamed TIDAL (or I believe Qobuz) content. It has some quirks, and I never personally cared for the UX, but it does the job both on-device and especially with external DACs.

There’s an MQA Core-Decoder (first unfold) option for UAPP as well.

You don’t need to be playing Hi-Res content to get a benefit from it, however, as it is one of the few applications that doesn’t subject what you’re playing to a low-rent forced ASRC to 48 kHz, which has it’s own benefits beyond lossless or MQA content.

5 Likes
8

For playing local files I can highly recommend Neutron App. I prefer the UI to UAPP, and for the EQ junkies amongst us it supports a seemingly unlimited number of parametric filters as opposed to UAPP’s limit of 6.

6 Likes
9

Silly question, but is this also the case for Android based DAPs?

10

IIUC, most Android-based DAPs suffer from the same problem at the OS level but get around the issue in their own custom music player programs. At least one, the Hiby R6, actually solves it at the hardware level so that you can run any Android-based software and benefit from their solution.

4 Likes
11

It depends on the specific DAP and, in some cases, how you’re playing music on that DAP.

Some use the stock Android audio-stack, some use a customized/modified audio-stack, and some rebuilt it in it’s entirety to avoid the issues. And some only use the custom audio-stack with their built-in music player application, but leave third-party apps like the TIDAL or Spotify clients to use the stock audio-stack.

Price and pedigree of the player wasn’t a good indication of how it was handled, either. For example the initial Onkyo DP-X1 (and I believe the DP-X1A) used the stock Android audio-stack and, as I recall, a single 48 kHz sample-clock (the default for the Android platform), where as the much less expensive FiiO X5iii used a custom one.

The A&K players have a fully-custom audio stack and even third-party applications output is routed through these as it is a complete replacement for the stock implementation.

It varies by vendor and device and you need to check specifically. If it not called out specifically, I would work on the assumption that you’re going through the default stack and forced ASRC.

4 Likes
12

Please excuse me for all the questions here, but…

My portable setup is currently an Android phone via USB to the Topping NX4 DSD. My main usage with this set up is Spotify (90% of the time) although I do have some FLAC files on the phone.

I am guessing, please correct me, that by using Bluetooth, this would bypass the native audio stack?

So, if I were to add something like the Shanling M0 as a transport into the DAC, connecting via LDAC, this would bypass any of these issues (while also giving me extra space for FLAC files if I wish)?

1 Like
13

You would avoid the potential for forced ASRC with Android, but you run into other issues.

LDAC is only situationally lossless.

Most devices default to “Connection Priority” mode, which results in not using the full available bandwidth - at which point it operates as a dynamically adaptive lossy-codec and, fundamentally, doesn’t perform meaningfully differently to, say, aptX or AAC. It makes different qualitative trade-offs, but it still makes trade-offs to get around the reduced bandwidth.

I very much doubt the default mode for LDAC on the M0 is “Quality Priority”, and even if it is, it’ll then have to rely on near-ideal conditions to maintain a drop-out free full-speed connection. Conditions that, even when present, don’t seem to get exploited reliably by anything but some very specific hardware. Sony’s NW-WM1A/Z and Z300 players seem to manage to maintain the maximum quality, particularly with the WM-1000XM2 and XM3 headphones, but otherwise you typically see lower bit-rates (the 660 or 330 kbps rates), and that means lossy, adaptive, compression.

Try that with, say, one of the latest Google Pixel phones and it’ll default to the lowest LDAC connection speed, which isn’t as good as the much more common, and less-demanding of ideal radio conditions, aptX.

Why not just connect the M0 to the NX4 DSD via a short USB cable? The M0 supports USB output and the NX4 DSD can take USB input … so why do wireless at all? Especially if you weren’t with your phone.

3 Likes
14

If you can gain superuser/root access on an android device, you can modify the build.prop file to allow the DAC to take over sampling, but it’s not super easy. Some devices already do it by default, and some don’t.

I recently got the Fiio M6 to use as a tiny LDAC transport with android. It’s just too slow and has too little RAM to use LDAC on highest quality settings and only works consistently in Connection-First priority

3 Likes
15

This is currently the most common occurrence with non-Sony LDAC sources. The only Android device I know of that consistently does LDAC at 990 kbps, and doesn’t fall apart when the wind shifts, is the LG V30. Everything else seems to force, or default, to connection-priority and then runs at 330 kbps or sometimes 660 kbps rather than the full-fat 990 kbps.

Now, a WM1Z → 1000XM3 seems unflappable in “Quality Priority” mode, at the same ranges and conditions as aptX is comfortable with. But that’s far from the norm, sadly.

3 Likes
16

UAPP seems to have a simple - too simple - and somewhat deficient UI. Plus, when it works it works well, but I have found inexplicable failures and unexplainable successes. Then the planets re-align and it’s reversed.

Neutron I’ve used for years. And I still haven’t figured out the UI. Perhaps because I need to get drunk before I tackle the docs.

3 Likes
17

Due to the M0 not doing Spotify.

The majority of my portable listening is done with Spotify and it seems that DAPs that support Spotify are Android based and usually the size of a phone anyway.

I already have to carry my phone 24/7 so I guess I am just too lazy to want to swap backwards and forwards. My original idea was the BTR3 or the ES100 but the M0 seemed to have a little added functionality.

It’s all about picking the tradeoffs I guess.

Thanks for all your input and explanations!

2 Likes
18

After learning some interesting info from @Torq in this thread, I decided to do some tests to see what sort of differences I heard using various setups on my Android devices. I hope this is not too off topic for the thread!

My phone is a Xiaomi Redmi Note 4 (RN4), which has a “Hi-Res DAC capable of 24/192”. I can’t find what the specific DAC is but I haven’t really looked very hard!

I have a second device, a Xiaomi Redmi Pro (RP), which I only really use around the house to either control Raspotify or to stream via bluetooth.

For the tests I used the two devices along with a Topping NX4 DSD and the Tin T2 (and briefly the Beyerdynamic Custom Studio Pro). For audio, I picked two albums that I had on hand in both FLAC and MP3 320Kbps, I also used the same albums on Spotify, these were “Eagles - Hell freezes over” and “Queen - Made in heaven”.

The first simple test was to listen to both of them via Spotify on both devices. The result was that the RN4 sounded much better than the RP, the difference was very clear.

Next I tried Spotify vs MP3 using Foobar2000 for Android on the RN4. I could not tell the difference.

I then installed UAPP (I had never used this before) on the RN4. When opening the first time it said something like “a HiRes DAC is present on this device and will be used”. This time I played Spotify vs MP3 in UAPP and the difference was very clear. The T2’s came alive and so did the music.

Next I compared MP3 to FLAC on the RN4, using UAPP and the headphones. I again noticed an improvement with FLAC over MP3, but I would venture to say that although it was very noticeable, I wasn’t as suprised as with the jump from Spotify to UAPP. It may just be placebo based on what I have learned in this thread.

Then I tried using the NX4 DSD connected to the RN4, comparing the onboard headphone socket vs the external DAC, using FLAC in UAPP. Again there was a difference but it was probably the smallest difference of all the tests. I went back and forth a few times and I am not sure I could guess 100% of the time correctly if I was to do this test blind.

Next I installed UAPP on the RP and performed the same tests as on the RN, While the differences etween Spotify and UAPP were there, and also the differences between Mp3 and FLAC, none of these combinations sounded anywhere near as good as the RN4. The headphone output of the RN4 is clearly superior to the RP.

When using the NX4 DSD as and external DAC from UAPP, there is no difference that I can find between the RN4 and RP, which is to be expected.

Finally, as I was impressed with the sound of the T2 being fed directly from the headphone socket of the RN4, I tried powering the Beyer CSP with it (80Ohm headphones). This didn’t go so well. While my listening level with the T2 was around 75%, with the CSP I turned the RN4 to 100% and it was certainly not loud enough and sounded muffled.

Anyway, random non relevant tests aside, thanks @Torq for the explanations you gave which have led me to do these tests, I love feeling that i have learned something new :wink:

(Edit: see other post below for clarification on a user error!)

4 Likes
19

If you want to really geek out on this stuff and know how to connect the Android debugger to your phone, you can inspect what’s going on while your music is playing.

adb shell dumpsys media.audio_flinger

The result of this command will list multiple outputs. You want to find the one that says 1 Tracks of which 1 are active.

If I’m playing a CD quality FLAC rip from Neutron, I get something like this:

Output thread 0xe1634000, name AudioOut_AF5, tid 7875, type 1 (DIRECT):
  I/O handle: 2805
  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)
  Audio source: 0 (default)
  Normal frame count: 1792
  Last write occurred (msecs): 34
  Total writes: 1960
  Delayed writes: 0
  Blocked in write: yes
  Suspend count: 0
  Sink buffer : 0xe1389000
  Mixer buffer: 0xe20d9800
  Effect buffer: 0xe31e3800
  Fast track availMask=0xfe
  Standby delay ns=1000000000
  AudioStreamOut: 0xe4587940 flags 0x1 (AUDIO_OUTPUT_FLAG_DIRECT)
  Frames written: 3512320
  Suspended frames: 0
  Hal stream dump:
  Stream volumes in dB: 0:-10, 1:-25, 2:-19, 3:-17, 4:-23, 5:-23, 6:0, 7:-18, 8:-21, 9:-96, 10:-22, 11:0, 12:0
  Normal mixer raw underrun counters: partial=0 empty=0
  1 Tracks of which 1 are active
    Name Active Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB  VS dB    Server Main buf  Aux buf Flags UndFrmCnt  Flushed
    none    yes   8660    3 00000006 00000003    3817   6720 A 3 44100     0     0     0   00359F00 E1389000 00000000 0x000         0        0
  0 Effect Chains
  Local log:
   04-06 07:54:22.428 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
   04-06 07:54:22.441 addTrack_l    (0xe220ee00) none     no   8660    3 00000006 00000003    3817   6720 A 1 44100     0     0     0   00000000 E1389000 00000000 0x000         0        0

I can see that the sample rate is correct at 441000 Hz and that it’s using DIRECT output (which means we’re bypassing the mixer). The fact that the audio stream is in 24 bit is actually crucial here. My source file is 16 bit, however players like Neutron and UAPP pad everything to 24 bits as a trick to bypass Android’s mixer, which only handles 16 bit audio.

When playing something from Google Play Music, I get this:

Output thread 0xe1608000, name AudioOut_AFD, tid 8447, type 4 (OFFLOAD):
  I/O handle: 2813
  Standby: no
  Sample rate: 44100 Hz
  HAL frame count: 65536
  HAL format: 0x1000000 (AUDIO_FORMAT_MP3)
  HAL buffer size: 65536 bytes
  Channel count: 2
  Channel mask: 0x00000003 (front-left, front-right)
  Processing format: 0x1000000 (AUDIO_FORMAT_MP3)
  Processing frame size: 1 bytes
  Pending config events: none
  Output device: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
  Input device: 0 (AUDIO_DEVICE_NONE)
  Audio source: 0 (default)
  Normal frame count: 65536
  Last write occurred (msecs): 1184
  Total writes: 7
  Delayed writes: 0
  Blocked in write: no
  Suspend count: 0
  Sink buffer : 0xe45db000
  Mixer buffer: 0xe0f80000
  Effect buffer: 0xe1883000
  Fast track availMask=0xfe
  Standby delay ns=1000000000
  AudioStreamOut: 0xe4587500 flags 0x31 (AUDIO_OUTPUT_FLAG_DIRECT|AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD|AUDIO_OUTPUT_FLAG_NON_BLOCKING)
  Frames written: 200620
  Suspended frames: 0
  Hal stream dump:
  Stream volumes in dB: 0:-10, 1:-25, 2:-19, 3:-17, 4:-23, 5:-23, 6:0, 7:-18, 8:-21, 9:-96, 10:-22, 11:0, 12:0
  Normal mixer raw underrun counters: partial=0 empty=0
  1 Tracks of which 1 are active
    Name Active Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB  VS dB    Server Main buf  Aux buf Flags UndFrmCnt  Flushed
    none    yes   7236    3 01000000 00000003    3793  65536 A 3 44100     0     0     0   00040FAC E45DB000 00000000 0x000    192596        0
  0 Effect Chains
  Local log:
   04-06 07:58:10.039 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
   04-06 07:58:10.047 addTrack_l    (0xe317e800) none     no   7236    3 01000000 00000003    3793  65536 A 1 44100     0     0     0   00000000 E45DB000 00000000 0x000         0        0

Interestingly this is not using the MIXER output but rather OFFLOAD because it’s actually delegating MP3 decoding to the hardware level. I’m not really sure if/how the mixer is involved in this particular path.

And lastly here’s what it looks like when I’m playing a podcast from Castbox.

Output thread 0xe3303a00, name AudioOut_15, tid 1668, type 0 (MIXER):
  I/O handle: 21
  Standby: no
  Sample rate: 48000 Hz
  HAL frame count: 1920
  HAL format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
  HAL buffer size: 7680 bytes
  Channel count: 2
  Channel mask: 0x00000003 (front-left, front-right)
  Processing format: 0x1 (AUDIO_FORMAT_PCM_16_BIT)
  Processing frame size: 4 bytes
  Pending config events: none
  Output device: 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
  Input device: 0 (AUDIO_DEVICE_NONE)
  Audio source: 0 (default)
  Normal frame count: 1920
  Last write occurred (msecs): 23
  Total writes: 81157
  Delayed writes: 0
  Blocked in write: yes
  Suspend count: 0
  Sink buffer : 0xe4a63000
  Mixer buffer: 0xe4345000
  Effect buffer: 0xe4a71000
  Fast track availMask=0xfe
  Standby delay ns=3000000000
  AudioStreamOut: 0xe4a5af20 flags 0x8 (AUDIO_OUTPUT_FLAG_DEEP_BUFFER)
  Frames written: 155821440
  Suspended frames: 0
  Hal stream dump:
  Thread throttle time (msecs): 966
  AudioMixer tracks: 0x00000001
  Master mono: off
  No FastMixer
  Stream volumes in dB: 0:-10, 1:-25, 2:-19, 3:-17, 4:-23, 5:-23, 6:0, 7:-18, 8:-21, 9:-96, 10:-22, 11:0, 12:0
  Normal mixer raw underrun counters: partial=0 empty=0
  1 Tracks of which 1 are active
    Name Active Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB  VS dB    Server Main buf  Aux buf Flags UndFrmCnt  Flushed
       0    yes   8569    3 00000001 00000001    3825  14144 A 3 44100     0     0     0   000143DC E4A63000 00000000 0x000      1768        0
  0 Effect Chains
  Local log:
   04-05 11:52:31.785 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 11:52:31.790 addTrack_l    (0xe220df00)    0     no   6441    3 00000001 00000003    2265  14144 A 1 44100     0     0     0   00000000 E4A63000 00000000 0x000         0        0
   04-05 11:53:19.283 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 11:53:21.002 removeTrack_l (0xe220df00)    0     no   6441    3 00000001 00000003    2265  14144 T 1 44100     0     0     0   0020F220 E4A63000 00000000 0x404         0        0
   04-05 12:00:07.392 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-05 13:06:44.465 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 13:06:44.467 addTrack_l    (0xe317e200)    0     no   6441    3 00000001 00000003    2265  14144 A 1 44100     0     0     0   00000000 E4A63000 00000000 0x000         0        0
   04-05 13:06:52.286 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 13:06:53.527 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 13:06:54.286 removeTrack_l (0xe317e200)    0     no   6441    3 00000001 00000003    2265  14144 T 1 44100     0     0     0   000675C0 E4A63000 00000000 0x404         0        0
   04-05 13:06:54.464 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-05 13:13:48.705 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 13:13:48.710 addTrack_l    (0xe220f100)    0     no   6441    3 00000001 00000003    2265  14144 A 1 44100     0     0     0   00000000 E4A63000 00000000 0x000         0        0
   04-05 13:19:05.366 removeTracks_l(0xe220f100)    0     no   6441    3 00000001 00000003    2265  14144 P 3 44100     0     0     0   00D4F6A0 E4A63000 00000000 0x400         0        0
   04-05 14:52:54.233 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-05 15:51:24.057 removeTrack_l (0xe220f100)    0     no   6441    3 00000001 00000003    2265  14144 T 3 44100     0     0     0   00D4F6A0 E4A63000 00000000 0x400         0        0
   04-05 17:08:28.206 removeTrack_l (0xe220e380)    0     no   2488    3 00000001 00000003    2633   1772 T 0 22050     0     0     0   00000000 E4A63000 00000000 0x000         0        0
   04-05 17:08:53.328 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x1 (AUDIO_DEVICE_OUT_EARPIECE)
   04-05 17:08:55.758 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x1 (AUDIO_DEVICE_OUT_EARPIECE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 17:12:56.046 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0x1 (AUDIO_DEVICE_OUT_EARPIECE)
   04-05 17:13:23.069 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x1 (AUDIO_DEVICE_OUT_EARPIECE) new device 0 (AUDIO_DEVICE_NONE)
   04-05 17:29:13.474 removeTrack_l (0xe317d480)    1     no   2488    3 00000001 00000003    2777   1772 T 0 22050     0     0     0   00000000 E4A63000 00000000 0x000         0        0
   04-05 17:36:44.845 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x1 (AUDIO_DEVICE_OUT_EARPIECE)
   04-05 17:36:47.543 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0x1 (AUDIO_DEVICE_OUT_EARPIECE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 17:39:32.907 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-05 17:39:34.283 addTrack_l    (0xe317da80)    0     no  16344    3 00000001 00000003    2737  33075 A 1 44100     0     0     0   00000000 E4A63000 00000000 0x004         0        0
   04-05 17:39:34.539 removeTrack_l (0xe317da80)    0     no  16344    3 00000001 00000003    2737  33075 T 1 44100     0     0     0   000014AC E4A63000 00000000 0x404         0        0
   04-05 17:39:34.580 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 17:52:24.811 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-05 23:31:38.594 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-05 23:31:38.595 addTrack_l    (0xe317d180)    0     no   7800    3 00000001 00000003    3673  24960 A 1 48000  -inf  -inf     0   00000000 E4A63000 00000000 0x000         0        0
   04-05 23:31:41.278 removeTrack_l (0xe317d180)    0     no   7800    3 00000001 00000003    3673  24960 T 1 48000  -inf  -inf     0   0001C980 E4A63000 00000000 0x601      1922    21120
   04-05 23:58:26.878 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-06 00:08:52.907 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x2 (AUDIO_DEVICE_OUT_SPEAKER)
   04-06 00:08:52.916 addTrack_l    (0xe317e500)    0     no  18361    3 00000001 00000003    3713  14144 A 1 44100     0     0     0   00000000 E4A63000 00000000 0x000         0        0
   04-06 00:09:00.879 removeTracks_l(0xe317e500)    0     no  18361    3 00000001 00000003    3713  14144 P 3 44100     0     0     0   000538C8 E4A63000 00000000 0x400      1768        0
   04-06 00:22:44.784 removeTrack_l (0xe317e500)    0     no  18361    3 00000001 00000003    3713  14144 T 1 44100     0     0     0   000538C8 E4A63000 00000000 0x600      1768    14144
   04-06 07:47:37.847 CFG_EVENT_RELEASE_AUDIO_PATCH: old device 0x2 (AUDIO_DEVICE_OUT_SPEAKER) new device 0 (AUDIO_DEVICE_NONE)
   04-06 07:59:38.871 CFG_EVENT_CREATE_AUDIO_PATCH: old device 0 (AUDIO_DEVICE_NONE) new device 0x8 (AUDIO_DEVICE_OUT_WIRED_HEADPHONE)
   04-06 07:59:38.878 addTrack_l    (0xe220f100)    0     no   8569    3 00000001 00000001    3825  14144 A 1 44100     0     0     0   00000000 E4A63000 00000000 0x000         0        0

This is going through the mixer at 48 KHz sample rate.

6 Likes
20

I am quoting myself here as I noticed today (while trying to fix some other very irritating Xiaomi issues) that somehow and sometime I had switched Spotify to Normal rather than Extreme quality.

Now that would explain the huge difference I heard between Spotify and UAPP with the 320kbps file.

However, it doesn’t explain why I couldn’t hear a difference between Spotify and Foobar on my phone.

Oh well, I would retest but I have other toys to play with for now :wink:

1 Like