Verified hardware

Does the Jcally JM6 Pro run bit-perfect on Android?

Yes. Meringo has captured bit-identical output from the Jcally JM6 Pro at 24-bit / 96 kHz, and the SHA-256 of that capture is published in full. You do not have to trust us on it: the same hash is recomputable with ffmpeg, which is a tool we do not control.

The receipts

Two captures, six weeks apart, on two different builds. Both bit-identical.

Jcally JM6 Pro BIT-IDENTICAL ✓

UAC1 high-speed sync · CX31993 + MAX97220
96 kHz · 24-bit on the wire · FLAC
Meringo 1.31.0 (130) · 2026-08-01

SHA-256 · capture = source847af9e41aebc5684ce36909f8417ed22d65bb1909b6de05428f160fe32cd4a7

★ Same file, same hash as a Qudelix 5K capture that day — the paired receipt →

Jcally JM6 Pro BIT-IDENTICAL ✓

UAC1 high-speed sync · CX31993 + MAX97220
96 kHz · 16-bit on the wire
Meringo 1.28.5 (124) · 2026-06-19

SHA-256 · capture = sourceb896aa7f8fd97b1084585669214bac23f2392a77a4b1144cecba8f05b71001fe

Two DACs, one hash

The 24/96 capture above has a twin. On 2026-08-01 the same 96 kHz / 24-bit FLAC was played through the JM6 Pro and through a Qudelix 5K, on different chipsets and different USB timing, and both captures hashed to the same SHA-256.

We had wondered whether two cheap dongles would actually agree at the byte level. They did, and that is the whole point of a receipt: one file, two physically different DACs, one hash means nothing in either path altered a byte on the way out.

Fair warning on what that proves. A hash covers what Meringo put on the USB wire. Isochronous USB carries no delivery acknowledgement, so no software on any platform can prove what the DAC received — only what was put on the wire for it. We print that boundary because it is the honest edge of the claim.

What “UAC1 high-speed sync” means here

The JM6 Pro enumerates as a USB Audio Class 1 device in high-speed synchronous mode. The receipt names its chipset too, CX31993 + MAX97220, because a receipt records one specific piece of hardware on one specific day rather than a product category.

For bit-perfect purposes the USB class is the less interesting half. What decides it is whether the bytes leaving the phone are the bytes that were in the file, and that is the only thing the receipt claims.

Why any of this needs proving

By default, Android resamples your music to 48 kHz. Plugging in a capable dongle does not by itself change that, and nothing on screen tells you it happened, because resampled audio still sounds like music. You can own a good DAC, play a 96 kHz file, and get 48 kHz out of the other end with no warning at all.

A hash settles the argument. Either the captured bytes match the source or they do not.

Check it yourself

Every entry in the registry is recomputable without Meringo running, using ffmpeg and sha256sum. The method and a public-domain checker script are published at meringo.app/verify, and that script shares no code with the app. If your own capture of a JM6 Pro disagrees with ours, send us the receipt: NOT BIT-IDENTICAL and INCONCLUSIVE are both published verdicts, and every verdict is welcome.

The receipt registry

What we do not claim

The published JM6 Pro captures are at 96 kHz, at 24-bit and at 16-bit. We have not published a receipt for this dongle at any other rate or depth, so treat anything else as unverified until it turns up in the registry.

We hold receipts for three DACs today. If yours is not one of them, we do not know that it runs bit-perfect and we will not say that it does. There is no compatibility list assembled from spec sheets here, because a spec sheet describes what hardware can do and a receipt records what actually happened.

Meringo is also the wrong player for you if you mainly stream from Spotify, Tidal or Qobuz. There is no native integration with commercial streaming, by design.