When 'no DAC' isn't no DAC

A 1-bit user plugged Audeze SINE headphones with the Cipher Lightning cable into an iPhone 13, opened the app, and reported that it “acted as if there was no DAC.”

A note before we start: both the SINE and the Cipher cable are discontinued — Audeze stopped making the SINE around 2019, and the Cipher cable has been listed as discontinued by retailers since. Used units still circulate on the secondhand market, and a non-trivial number of audiophiles are still using them daily. The specific hardware in this story is fading out, but the technical predicament I’m about to describe applies to every Lightning DAC ever made and to every USB-C audio dongle on shelves today. iPhones moved to USB-C with the iPhone 15, and the iOS-side problem moved with them.

The Cipher cable is a DAC. The Lightning port on iPhones is purely digital — every Lightning headphone or audio adapter contains its own digital-to-analog converter, by definition. Audeze’s Cipher goes further: 24-bit / 48 kHz DAC plus a small DSP that runs Audeze’s own EQ for the SINE / iSINE / LCD-i headphones. The cable retailed for about $250 when new.

So when an audiophile-focused music player tells the user “no DAC,” it’s wrong on the facts. But it’s also reflecting something real: from the app’s perspective, this hardware is indistinguishable from a $9 plastic dongle.

Here’s why.

What iOS gives you

When an audio device is connected, iOS exposes it through AVAudioSession. The output port has three string fields a third-party app can read:

• portType — a coarse category. Lightning headphones land on .headphones.
• portName — a human-readable name. iOS reports "Headphones".
• uid — a unique identifier you’d hope was model-specific. iOS reports "Wired Headphones".

These are the strings for the Cipher cable, and for Apple’s own EarPods Lightning, and for any random no-name Lightning headset. On iPhone 15 / 16 with USB-C, plug in a $9 USB-C-to-3.5mm dongle or a $1500 portable USB DAC and AVAudioSession reports the same thin set of generic strings for both. Apple’s audio API treats them as equivalent — identical text labels for hardware that ranges from worthless to high-end.

There’s a reason for this. Apple’s design philosophy with AVAudioSession is abstraction: audio apps shouldn’t have to write custom drivers for every dongle on the market. From the OS’s point of view, all of those devices accept PCM audio at compatible rates over the same connector. The differences (max sample rate, DSP capability, headphone-driver pairing) are hidden because exposing them would push complexity onto every audio-app developer.

For 99% of audio apps, that abstraction is exactly right. For an app whose entire identity is bit-exact playback to whatever DAC the user has invested in, it’s painful.

What I tried before giving up

The instinct of a stubborn engineer is to look elsewhere. There must be some way to learn the model.

• USB descriptors. Class-compliant USB DACs identify themselves with a Vendor ID and Product ID — a manufacturer-specific pair of numbers that uniquely names them. On Linux, macOS, or Windows, an app can read these directly. On iOS, IOKit (the framework that exposes them) is unavailable. CoreMIDI doesn’t surface them either. Apple has deliberately left no public API for an app to read VID/PID for an audio device.
• AVAudioSession’s port descriptions. As above — the strings are generic and intentionally so.
• Bluetooth or AirPlay metadata. Doesn’t apply — Cipher is wired, and the same problem exists for wired USB-C DACs.

So an iOS app cannot, by any supported route, learn that the connected output is anything more specific than its broad port category.

The MFi back-channel

There is a way to see Lightning hardware in detail. It’s just not available to most apps.

Apple’s MFi program (Made for iPhone) certifies accessories through an authentication chip embedded in the cable. When an MFi accessory is plugged in, iOS reads the chip and learns what the accessory says about itself: manufacturer, model, firmware version, capabilities. An app can read all of this through the External Accessory framework — but only if the app declares the manufacturer’s specific protocol string (something like com.audeze.cipher.audio) in its Info.plist under UISupportedExternalAccessoryProtocols.

The catch: the manufacturer has to whitelist the app’s bundle ID before the app can use the protocol string. This isn’t a public API anyone can opt into — it’s a per-vendor, per-app handshake. Audeze’s own Audeze HQ app has the Audeze protocol string and Audeze’s blessing, so when you plug in the Cipher cable it can read the model, adjust the 10-band EQ stored in the cable’s flash, and update the cable’s firmware. My app, or any third-party music player, can’t see any of that — by design.

The result is a quiet asymmetry that audiophile customers don’t usually notice: the manufacturer’s app gets the rich hardware view; everyone else gets "Headphones". There’s no public API I can write that bridges this gap. I’d need a partnership with Audeze — and even then, only Audeze hardware would benefit. The same pattern exists for USB-C DACs, with a similar set of vendor-specific protocols (Apple has not opened the framework up; they’ve only widened the connector).

The fix

Once you accept that you cannot identify the DAC, the fix is just: be honest about what you don’t know.

The original UI had a green Verified DAC card that appears in the now-playing signal-path sheet when the app’s known-DAC list matches by name. For Chord, iFi, FiiO, Topping, AudioQuest’s DragonFly Cobalt, and a handful of others, that match works because their USB DACs report a model-specific name in portName. For anything iOS labels generically — Cipher among them — no match, no card. The user reads the missing card as “the app doesn’t see my DAC.”

The fix:

• For external outputs without a profile match, render a neutral grey card that says “External output detected · Standard audio path” alongside whatever name iOS gave us (often just “Headphones”). It looks nothing like the green Verified card, deliberately.
• It does not say “bit-exact path active.” That would be a lie. iOS may apply sample-rate conversion silently if the stream exceeds the hardware’s ceiling — and the same UI shows an orange resampling indicator when that happens. A “bit-exact” claim alongside an “iOS is resampling” indicator would be a direct contradiction.
• For DSD playback errors on unprofiled hardware, the error message now leads with the most likely cause: “The connected output likely doesn’t support DSD (some Lightning headphones and USB-C dongles are PCM-only).” Less mystery, more useful.
• For accessibility, the card combines into a single VoiceOver element with an explicit label — “External output detected: Headphones. Capabilities aren’t in our profile list. DSD may not negotiate.” — instead of forcing a screen reader user to swipe through icon, title, subtitle, info-glyph one element at a time.

That’s the whole fix. No new API surface, no new heuristic, no fragile guesses. The only thing it really does is replace the absence of a green card with the presence of a neutral one.

What I learned

Two things stick.

First: absence of information is different from absence of the thing. The original UI was technically correct — there was no “Verified DAC” card because no profile matched — but the user read it as “no DAC.” The presence of an explicit “External output detected” card uses no new information, and yet completely removes the perception. The most common UX bug in audiophile software, in my experience, is the same as the most common UX bug elsewhere: silently saying nothing when you should say “I’m not sure.”

Second: Apple’s privacy and security philosophy has audiophile collateral, and the lesson outlives the hardware. The MFi walled garden is mostly a good thing — it stops malicious accessories from impersonating each other and stops apps from fingerprinting users by their dongle pile. But it also means that the most basic question an audiophile asks (“is my expensive cable being recognized?”) cannot be answered honestly by any app the manufacturer hasn’t blessed.

The Cipher cable that started this story is discontinued. The DAC chip in your USB-C dongle, whoever made it, is not. If you’ve ever wondered why a music player says “Output: Headphones” while a piece of expensive hardware blinks proudly on your desk, this is why. The DAC is there. The app just isn’t allowed to know its name.