[gregorio]

1. If a DAC is connected via USB to an android device and is sound is being directed through the USB DAC, can it be concluded that the external device is being implemented correctly and will sound identical to any source (i.e. PC)?
2. Are there any audible differences when using apps like UAPP? (if so, what is the cause of the change?)
3. Does android always re-sample to a standard sample rate and does this create an audible difference?
4. Based on your responses it is implied that my perceived audio quality improvements are caused by varying volume levels and in fact the external DAC is producing exact same sound. This could very well be the case as I haven't done the required tests to rule this out. Would you extend this thinking to comparing DAC vs DAC or AMP vs AMP? i.e. are there noticeable improvements in sound reproduction with these varying components? ... I'm just trying to find out which hairs are worth splitting.

1. Assuming that the differences in output (EG. Power/impedance) of the two devices are appropriate for your transducers (speakers or headphones) then "yes" it can generally be concluded that the differences will be inaudible. However there are some potential caveats: There are some external DACs that do not isolate their analogue output very well from the high levels of noise output by some PCs on their USB ports. However, there are probably exceedingly few DACs (even with very noisy PCs) where the levels of analogue output noise is actually audible. And:

2. I don't know specifically with the UAPP app. There can be audible differences with different software: I verified a difference between Firefox and Safari (with a blind test) on a Mac and, that Safari's output was higher fidelity but didn't have time to investigate what Firefox was doing to reduce fidelity. (This was with a several year old version of Firefox).

3. I believe that android does always re-sample but that it can be bypassed with certain software. Again, I haven't specifically test what android does but as a general rule, changing sample rates creates NO audible difference. There were some exceptions to this rule, a couple of decades ago with certain sample rate converters. So, while I can't be absolutely certain, I would be very surprised in android caused any audible artefacts from it's SRC and I would need some very reliable evidence that it does.

4. As a general rule DAC vs DAC and Amp vs Amp is NOT "a hair worth splitting". Even quite cheap DACs (<$80) can be audibly transparent and differences between amps are generally inaudible (given appropriate output power/impedance). However, there are a few esoteric design exceptions in both cases, some valve amps for example.

[1] Even via Android, LDAC will not sound as good as the resampled usb audio via your phone.
[2] UAPP with no resampling sounds better than audio running through Android audio stack.
[3] That's just unfortunately how Linux/Android operate.

1. Assuming "not sound as good" means audibly poorer fidelity, we will need some reliable evidence of that assertion please.

2. Same again, some reliable evidence please.

3. If there is reliable evidence that UAPP with no resampling is audibly better (fidelity) and if so, that resampling is actually the cause, then it would indeed be very unfortunate, arguably to the point of incompetence!

G

 

[Devodonaldson]

1. Assuming that the differences in output (EG. Power/impedance) of the two devices are appropriate for your transducers (speakers or headphones) then "yes" it can generally be concluded that the differences will be inaudible. However there are some potential caveats: There are some external DACs that do not isolate their analogue output very well from the high levels of noise output by some PCs on their USB ports. However, there are probably exceedingly few DACs (even with very noisy PCs) where the levels of analogue output noise is actually audible. And:

2. I don't know specifically with the UAPP app. There can be audible differences with different software: I verified a difference between Firefox and Safari (with a blind test) on a Mac and, that Safari's output was higher fidelity but didn't have time to investigate what Firefox was doing to reduce fidelity. (This was with a several year old version of Firefox).

3. I believe that android does always re-sample but that it can be bypassed with certain software. Again, I haven't specifically test what android does but as a general rule, changing sample rates creates NO audible difference. There were some exceptions to this rule, a couple of decades ago with certain sample rate converters. So, while I can't be absolutely certain, I would be very surprised in android caused any audible artefacts from it's SRC and I would need some very reliable evidence that it does.

4. As a general rule DAC vs DAC and Amp vs Amp is NOT "a hair worth splitting". Even quite cheap DACs (<$80) can be audibly transparent and differences between amps are generally inaudible (given appropriate output power/impedance). However, there are a few esoteric design exceptions in both cases, some valve amps for example.



1. Assuming "not sound as good" means audibly poorer fidelity, we will need some reliable evidence of that assertion please.

2. Same again, some reliable evidence please.

3. If there is reliable evidence that UAPP with no resampling is audibly better (fidelity) and if so, that resampling is actually the cause, then it would indeed be very unfortunate, arguably to the point of incompetence!

G

It's not just about sample rate conversion. Audio isn't always downsampled. Always a multiple of 48khz. It's more about the fact that the Android audio stack uses a SINC filter implementation optimized for power consumption rather than precision and exhaustion of the conversion coefficients.

 

[gregorio]

[1] It's not just about sample rate conversion. Audio isn't always downsampled. Always a multiple of 48khz.
[2] It's more about the fact that the Android audio stack uses a SINC filter implementation optimized for power consumption rather than precision and exhaustion of the conversion coefficients.

1. The clear implication of your post was that resampling was the issue and, of course, that's also the thread title.

2. Just rewording the assertion in more detail doesn't answer the question, it just means that I have to repeat the same question using the new "rewording". IE. Can you please provide some reliable evidence that the Android SINC filter implementation does in fact cause audible artefacts.

G

 

[List3n]

Even via Android, LDAC will not sound as good as the resampled usb audio via your phone. UAPP with no resampling sounds better than audio running through Android audio stack. That's just unfortunately how Linux/Android operate. Only choices are stream everything through UAPP, get an Android FAP that bypasses Android SRC, or just be OK with the best audio you get out of the DAC/AMP connected to your phone through the Android audio stack. I use BTR5 and ifi XDSD with an Android phone. USB trump's bluetooth on both devices. FYI, bluetooth audio is still sent through Android audio stack. Another reason bluetooth audio also sounds better using UAPP settings for bluetooth audio.

Hello: I enjoy reading all of the information provided in this forum. This is my first post and it is a question for you guys who know. Please excuse and feel free to correct/clarify any misused terminology in my query and thanks in advance for any answers you may have. I have UAPP and a Galaxy s8+ and am using Qobuz. I think I understand a little about the USB out and the bluetooth out of my phone. My question: Has the sound/signal that comes out of the 3.5mm jack of my Samsung galaxy s8 plus also been "sent through Android audio stack?"--OR, does the signal/sound out of the 3.5 mm jack output somehow avoid any Android Audio processing (perhaps just the sound signal from the Qobuz file to phone's DAC and amp and then out the phone in a "native" form? So essentially, while UAPP is helpful when using USB out and possibly also with bluetooth, what about 3.5mm headphone jack out?

 

[brazy001]

Hello: I enjoy reading all of the information provided in this forum. This is my first post and it is a question for you guys who know. Please excuse and feel free to correct/clarify any misused terminology in my query and thanks in advance for any answers you may have. I have UAPP and a Galaxy s8+ and am using Qobuz. I think I understand a little about the USB out and the bluetooth out of my phone. My question: Has the sound/signal that comes out of the 3.5mm jack of my Samsung galaxy s8 plus also been "sent through Android audio stack?"--OR, does the signal/sound out of the 3.5 mm jack output somehow avoid any Android Audio processing (perhaps just the sound signal from the Qobuz file to phone's DAC and amp and then out the phone in a "native" form? So essentially, while UAPP is helpful when using USB out and possibly also with bluetooth, what about 3.5mm headphone jack out?

While I don't have any evidence, I would think The 'Android audio stack' will be used to process audio regardless of USB or 3.5mm. it's only when another app i.e. UAPP which will use its own driver including sampling etc.

When I used UAPP with the 3.5mm Jack on my galaxy s10e I could not notice any difference between it and playing through tidal app directly.

Leaves me questioning whether there are any audible issues with the android drivers or its default resampling.

 

[bigshot]

I'm pretty sure Apple runs everything through its own audio processing too.

 

[Hotep303]

It's not just about sample rate conversion. Audio isn't always downsampled. Always a multiple of 48khz. It's more about the fact that the Android audio stack uses a SINC filter implementation optimized for power consumption rather than precision and exhaustion of the conversion coefficients.

Man Android audio processing is such a headache.

Can you point me please to resources that deal with bypassing it?
"get an Android FAP that bypasses Android SRC"

 

[gregorio]

Man Android audio processing is such a headache.

Can you point me please to resources that deal with bypassing it?

Why do you want to bypass Android's SRC?

Low power SRC was a potential issue 20 years or so ago but is trivial for a modern processor executing modern SRC algorithms. It would be more than surprising if Android's SRC was not audibly transparent, have you seen any reliable evidence that it isn't?

G

 

[Hotep303]

Why do you want to bypass Android's SRC?

Low power SRC was a potential issue 20 years or so ago but is trivial for a modern processor executing modern SRC algorithms. It would be more than surprising if Android's SRC was not audibly transparent, have you seen any reliable evidence that it isn't?

G

Yes. A/B'ing iBasso DC04 dongle DAC and switching between android audio and bitperfect streaming, even on 320 mp3 even with less volume on bitperfect - the android sounds very noticeably worse. That's all I know, don't know the causes or if it's just my particular chip that has this problem, but it's pretty stupid.

A/B with less than 2 seconds between audio. Volume adjusted in favor of Android... It just makes it sucky for some reason. I mean maybe not worse than headphone/type-C jack but very noticeably worse than bitperfect on the same app (HiBy), same file.

Currently hoping Bluetooth would at least partially avoid this issue so looking to buy Fiio UTWS5...

 

[bigshot]

Is this something that is common across all android devices, or just specific ones. How many different ones have you tested?

 

[Hotep303]

Is this something that is common across all android devices, or just specific ones. How many different ones have you tested?

Only one amp DC04 on two Xiaomi phones.

 

[gregorio]

[1] A/B'ing iBasso DC04 dongle DAC and switching between android audio and bitperfect streaming, even on 320 mp3 even with less volume on bitperfect - the android sounds very noticeably worse. [2] That's all I know, don't know the causes or if it's just my particular chip that has this problem, but it's pretty stupid.

[3] A/B with less than 2 seconds between audio. Volume adjusted in favor of Android... It just makes it sucky for some reason.

1. There's a few obvious problems here:
A. You can NEVER be sure there really is an audible difference unless you blind test (as opposed to A/B test), REGARDLESS of how obvious/big the difference appears to be.
B. "Less volume on bitperfect" is an oxymoron; changing the digital volume changes the bits and therefore cannot be bit-perfect.
C. In addition to "A", the volume should be accurately matched, NOT more or less volume.

2. The cause is pretty important for two reasons. Firstly, you may make false assertions and blame entirely the wrong thing, and secondly, the cause might be something you can easily defeat, such as replay-gain, a limiter or something else.

3. As per "C" above, the volume should be accurately matched because a higher volume is not necessarily "in favour of Android".

G

 

[TYATYA]

To reconstruct a circle, how many point you need?
3?
5?
And the same questions for a line?
2 point, right?

So, more means none when mathermatic proves it already.

44khz is enough to render 20khz tone - limit of normal teenage (not ave level of aldults).
I assume that 20k to 22k is inaccuracy zone for cut off curve is a slope with not perfect sharp.

Talking other than math, it is with tolerance -> if 96k sample was process badly compare to 44k sample, and assume that an individual can heard the difference. Then, what is BETTER? Can conclude 96 better with envidence?
I think no.

 

[bigshot]

Only one amp DC04 on two Xiaomi phones.

Then even assuming your observation is correct, which as Gregorio points out is a big assumption, then you have to make a few more assumptions to extrapolate results on one particular kind of phone to android devices in general. Then you have a couple more assumptions about the reason why.

 

[gregorio]

44khz is enough to render 20khz tone - limit of normal teenage (not ave level of aldults).

The topic isn't about sample rates but re-sampling and that can, or rather could, cause audible issues:

Low-quality resampling algorithms, whether upsampling or downsampling, can introduce artifacts which are clearly audible in the resampled audio file. A typical low-quality, but extremely fast resampling algorithm will just be based on linear interpolation. High-quality resampling algorithms use more CPU time, since they require translation to the frequency domain. Modern PC processors (~2 GHz clock) can easily deal with very high-quality resampling in real time.

The above quote is from Hydrogen Audio (Resampling wiki article) and was based on double blind testing. HOWEVER, it was written about 15+ years ago, when resampling algorithms were not as efficient as they are today and the "Modern PC processors (~2Ghz clock)" they're talking about was the 2002 Pentium 4, which had about 50 times less processing power than a current Snapdragon processor. So, it would be more than a little surprising if the Android SRC had any audible artefacts.

G