Search

WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

Measurements of Pixel 3 + Moshi headphone adapter + Google Play Music

Member

Here we go again, this time measuring a more expensive USB-C headphone adapter dongle. This is my second review, and I will follow a similar protocol to the previous one, with a few small changes.

The star of this show is the Moshi USB-C Digital Audio Adapter with Charging. This is an accessory that Google recommends, to the point of selling it themselves in their own store. It's also quite expensive compared to alternatives, even those that also allow charging. Moshi claims "pristine, high-resolution audio" with "regular 3.5 mm headphones", a "High-resolution Class G amplifier (24-bit/96 kHz)" and "ideal for audiophile libraries". Is it up to the hype? Let's find out!

You'll notice the change from the AIMP player to the Google Play Music player, which is the standard-issue player app on the Pixel 3. AIMP disappointed me in the previous review because it only supported a 48 kHz sample rate. Feed it anything else (even 44.1 kHz) and it will resample it, poorly. So this time I decided to use an app that hopefully will not suffer from such issues. (As we'll see later in this review, it indeed doesn't.)

Before we begin: if you're wondering whether we're going to see this weird "load impedance sensing" behaviour from the previous review again, the answer is no. As far as I can tell, this device behaves the same way no matter what is plugged into it.

PRELIMINARY MEASUREMENTS: SAMPLE RATE

Same thing as last time: let's play a few test signals, playing with the Nyquist frequency until we get a good sense of what we're dealing with.

I was able to measure the expected tone up to and including 24 kHz, indicating that the EUT does support a >48 kHz sample rate. I was unable, however, to measure anything with a 44.1 kHz tone, which either indicates the maximum sample rate is somewhere between 48 and 96 kHz (which would be weird), or, more plausibly, that the device frequency response simply does not reach that far. More on that later.

PRELIMINARY MEASUREMENTS: INTERSAMPLE PEAKS

Doing this test across many sample rates was useful the last time, so let's do that:

Here's how the waveform looks like, as seen through a high-speed oscilloscope, at the highest peak level:

While the EUT is of course distorting badly, this doesn't look nearly as bad as in the previous review where we could see some kind of "rail slamming" phenomenon - here the waveform is deformed, but is still recognizable.

However, we see this phenomenon again where, at 44.1 kHz, the distortion doesn't seem to follow the same periodic pattern, suggesting that the EUT might not be running at 44.1 kHz end-to-end - resampling might be happening somewhere.

Back to the QA401, a distortion spectrum measurement basically agrees with the above:

PRELIMINARY MEASUREMENTS: BIT DEPTH

Same thing as last time. I picked 48 kHz as the sample rate because the above makes me suspect the EUT cannot operate natively at 44.1 kHz, and DACs typically have a higher noise floor when running at 96 kHz.

When nothing is playing the DAC seems to shut down and leave outputs "floating", resulting in EMI noise such as mains hum showing up. This is typical and not really concerning, but I'll mention that the previous dongle behaved better in that regard IMHO, as it would simply short its output in that case, preventing EMI from getting in.

The difference in level between the -1 dB 997 Hz signal and -140 dB signal (drowned in the 16-bit dither, as expected) is 92 dB, which confirms we have access to the full 16-bit dynamic range.

The 16-bit and 24-bit "silence" measurements are identical, which suggests the EUT is not applying additional dithering on top of the source file.

Just like last time however, the low-level 24-bit measurements are a shit show:

That tone is supposed to be at -120 dBFS, but shows up at -91.4 dBFS instead, a completely insane 28.6 dB linearity error.

And, just like last time, distortion starts creeping into the 16-bit dither noise floor as soon as one reduces the volume, once again suggesting that the volume control is digital, not analog:

So once again we have an EUT that is incapable of behaving properly at low signal levels.

UNLOADED MEASUREMENTS: MAXIMUM OUTPUT VOLTAGE

The 997-1-48000-48 test signal registers at 0.0 dBV spot on, which means the maximum output level, unloaded, is +1 dBV, or 1.1 Vrms, or 1.6 Vp, or 3.2 Vpp. This is better than the previous review, and is somewhat average for that kind of hardware.

UNLOADED MEASUREMENTS: NOISE FLOOR AND DYNAMIC RANGE

The silence-24 test signal (see above) registers 98 dB below 997-1-48000-24, leading us to believe we have access to 98 dB of dynamic range, or a bit more than 16 bits, and a noise floor of -98 dBV.

But of course that would be too generous, because our bit depth measurements show that the EUT is not actually capable of delivering that noise floor with any kind of real signal other than pure silence. In practice, if we use the 997-140-48000-24 measurement which is more indicative of actual performance, we get 92.4 dB of dynamic range, which is closer to 15 bits than 16, and a noise floor of -92.4 dBV. That's mediocre.

I was curious to see how the noise floor looks like when the "charging" functionality of the dongle is being used - how well does it isolate from USB power supply noise? The answer is: very well - the noise floor measurements when charging (even fast charging) look pretty much identical to the others. This is true when using the official bundled charger, and also when using the shittiest, cheapest USB charger I had laying around.

UNLOADED MEASUREMENTS: THD AND THD+N/SINAD (997 Hz)

Unloaded, 997-1-48000-24 shows a THD of -78.9 dB (0.011%) and a SINAD of 77.6 dB (0.013% THD+N). This is well above the limits of the test equipment, so the results are valid.

This is even worse than the previous one, which was already pretty bad. So much for "pristine, high-resolution audio". Interestingly, the THD at -30 dBFS is vastly better (-94.4 dB), which indicates the EUT might be clipping a bit when driven at full scale. SINAD is worse at -30 dBFS, though.

UNLOADED MEASUREMENTS: FREQUENCY RESPONSE

Same protocol as last time; let's look at the results:

Lots of interesting stuff going on here.

First, the 48 kHz response looks good, with only +/-0.01 dB from 30 Hz to 7 kHz. From there it rises around 0.9 dB higher in the treble, but which is a bit concerning but arguably nitpicky. Then it's down only 3 dB at 23 kHz, which is excellent. It looks a bit too good, in fact, since it's down barely 6 dB at Nyquist - more on that below.

The 44.1 kHz response looks identical to the 48 kHz one. Google Play Music seems to be doing its job well by not resampling 44.1 kHz to 48 kHz. Or if it does, it seems to be doing it correctly, contrary to the AIMP app I was using in my previous review.

As for the 96 kHz response… well, isn't that laughable. Picture me saying "96 kHz" with massive air quotes. We do technically get a signal through above 24 kHz, but just barely - while the DAC seems to indeed be running at 96 kHz the cutoff frequency is the same as the other sample rate, which defeats the point of running at 96 kHz in the first place. This basically means this EUT only "supports" 96 kHz on paper, not in practice.

Now, the strange behaviour around 24 kHz and the whole "too good to be true" high-frequency roll-off made me suspicious. So I looked at the measured sweeps themselves and looked closely at the area near 24 kHz using spectrograms. I was not disappointed:

These, ladies and gentlemen, are textbook imaging artefacts. Now, granted, all of this snafu is happening above 20 kHz, but it could still be audible due to the intermodulation distortion that these spurious tones could cause in whatever device is plugged into the EUT.

The behaviour at 96 kHz is even more hilarious, because there we have egregious aliasing artefacts as well:

Now, one could argue this could yet again be some crappy resampler in the player app used (Google Play Music), just like AIMP had its own crappy resampler in the previous review. But the only way that would make sense with the above measurements is if the app was upsampling 44.1 kHz and 48 kHz to 96 kHz (otherwise it would be impossible for it to create artefacts above Nyquist), which seems unlikely. Also, I confirmed that the bundled dongle from my previous review does not do this, even with the Google Play Music app. This looks more like sloppy design in the Moshi DAC itself, specifically the reconstruction filter.

Note that all loaded measurements are done with both channels loaded and playing the same test signal, but only the left channel is measured.

The 997-1-48000-24 test signal registers at -17.2 dBV, which means the maximum output level, into 16.5 Ω, is -16.2 dBV, or 0.15 Vrms, or 0.22 Vp, or 0.44 Vpp. This translates to an output power of 1.4 mW into 16.5 Ω.

The difference with the maximum unloaded output voltage is completely explained by the output impedance, as we'll see below.

MEASUREMENTS INTO 16 Ω: THD AND THD+N/SINAD (997 Hz)

Here's how things look like at -1 dBFS into 16.5 Ω:

Into 16.5 Ω, 997-1-48000-24 shows a THD of -77.9 dB (0.013%) and a SINAD of 77.2 dB (0.014% THD+N). This is pretty much the same as the unloaded measurement, but do keep in mind the aforementioned reduction in output level.

MEASUREMENTS INTO 16 Ω: OUTPUT IMPEDANCE AND FREQUENCY RESPONSE

Same protocol as last time; let's look at the results:

From these measurements we can see that connecting a 16.5 Ω load makes the output level drop by 17.2 dB compared to no load. From there we can directly deduce that the output impedance is a constant 103.0 Ω.

Wait, what?

This result is so bad I had to do a double take and repeated the measurement with a 100 Ω load, just in case. I obtained the exact same result. Wow. This is hilariously bad, and much, much worse than the bundled Pixel 3 dongle.

Note that, because the output impedance is higher than the load impedance I tested with, the output power of the EUT actually increases with load impedance, peaking at 3.1 mW into 100 Ω, and then decreasing afterwards.

CONCLUSION

Of course the elephant in the room here is the absolutely atrocious output impedance of the Moshi. At 103.0 Ω this is extremely unsuitable for driving most headphones; it would be better suited as a simple line output. Aside from that, the distortion figures of the EUT are mediocre; the behavior of the DAC reconstruction filter is appalling for a device sold in 2019; and its 96 kHz "support" is laughable. The only thing good about this EUT is its excellent frequency response at 44.1 kHz and 48 kHz, but considering the above, what's the point? AVOID, especially at this price.

Additional note: I used this device during a trip, where there was only 2G phone coverage at times. I was shocked to realize I could hear the infamous GSM interference tone from the Pixel 3 itself in the noise floor! In other words, the Moshi, a phone accessory, does not have proper shielding against EMI coming from the phone it is connected to. WTF. This device really is a cruel joke. Even the bundled Pixel 3 dongle did not have that problem.

Android's audio is pretty much a deserted minefield. I wish they would go to just a modicum of trouble to fix it.

A suggestion on the dynamic range testing. Nothing wrong with what you are doing. But just to make it fit the AES 17 standard you can do a -60 db 1 khz tone. Notch out the tone and see what noise level is left. I usually do a notch filter with a Q of 12 and do it twice.

Member

Sadly, they are not consistent in that regard, because I think I've normalized the signal on the second one but not on the first one, and also I changed some options in the mean time. If you want more accurate data, you can download the raw measurement archive which contain the raw sweep measurements in the form of WAV files. You can then use any tool you want to get spectrograms out of them (I used Audacity for the screenshots).

The measurement archive only contains the measurements done on Android + Google Play Music. I did not keep the raw sweep measurement files for the Windows addendum. I can re-measure and add them if you're interested.

I'll try to be more consistent with the spectrograms in my future reviews. So far I was mostly using them for illustrative purposes to roughly show the behavior of the resampler (if any) near Nyquist.

Yeah. It looks like, today, the only way to get proper audio out of a standard Android Music Player is to (1) use a DAC that has an appropriate default gain (as opposed to, say, the Apple one), and (2) resample 44.1 kHz music to 48 kHz using a high-quality resampler (e.g. SoX) before putting it on the phone. This is sad.

A suggestion on the dynamic range testing. Nothing wrong with what you are doing. But just to make it fit the AES 17 standard you can do a -60 db 1 khz tone. Notch out the tone and see what noise level is left. I usually do a notch filter with a Q of 12 and do it twice.

Thanks for the suggestion. Yes, I'm aware my dynamic range testing is not consistent with AES17. I use a lazier method because I don't think I can do the notching directly in REW, so I would need to pre-process the measurement. If I find hardware that is worth spending the time for proper measurements, maybe I'll try to get a proper AES17 number then.

Actually the custom USB driver in the Onkyo app is a paid option as well. If I don't pay I get the same result as Google Play Music (i.e. resampling to 48 kHz).

Honestly I prefer having to pre-resample my music to 48 kHz if that means more choice of music player apps (audio quality is not my sole criteria). I don't want to be stuck with just a couple of paid apps, so I think I'm going to stick to standard apps and carefully avoid situations where the Android audio stack is going to mess up the signal.

Member

Hang on, does the Apple dongle have the same issue I had with my old Dragonfly Red on Android; the default hardware volume is set below 100%? I do wish they'd fix this and have an option to control hardware volume like they do for Bluetooth media... That said, there is a way to remedy this by launching UAPP, adjusting hardware volume there, then quitting the app from the notification tray, though this has to be done every time you plug it in.

As far as media player apps go, I just use Neutron for the huge amount of functionality and configuration available through it. I usually recommend UAPP for USB audio because its interface is easier to navigate, and its USB driver is a bit more robust and supports more devices that would otherwise behave weirdly on other apps. But both can do USB, and more importantly, output bit perfect audio to the phone's internal DAC if your SOC supports it.