(Mis)Understanding USB Audio

I have tried it with PC using Foobar, Tidal, Spotify and VLC, all with the same result (and on multiple machines, all running Windows 10).

I have tried it with various Android devices, using UAPP, same result (although I didn’t try all of the cables).

I have tried it with a Pi4 running RopieeeXL, same result as on PC.

It’s very weird.

I ordered a bunch of USB cables of various brands and will do some more testing, measure the output power etc.

Thanks for all the input so far, it certainly is a strange one.

1 Like

Have you tried it in a boat?
Have you tried it with a goat?
Have you tried it with a bee?
Have you tried it Senyor C?

  • apologies to the late Dr. Seuss
10 Likes

It certainly does seem to be a device malfunction/flaw (the DAC/amp combo, not the cables). Hopefully the manufacturer takes care of it quickly.

1 Like

This sort of thing is usually only encountered with either a) USB-powered devices, b) AC-powered devices that employ a galvanically isolated USB input or, most commonly, c) USB OTG-aware devices/chipsets (that then are not handling the ID pin state, or its absence, correctly).

In the latter case, the ID pin (pin “5”) is used during negotiation to determine what role the device plays, as well as charging/power-delivery/availability capacity. This pin isn’t present at all on standard (full-size) USB A/B connectors, and often isn’t connected on non-spec compliant/random-no-name cables.

Thus the behavior of the USB receiver has to correctly default the DAC’s configuration/behavior to handle cases when the ID state is not present or is in an incorrect state. Defaults vary, and can be overridden, in the various receiver implementations; a common default if the ID state is missing or invalid is to choose “low power” - so as to maximize the number of devices that it’ll work with*.

The end result is that the DAC/amp can wind up thinking it is limited to a low-power connection (e.g. it might default to low-power in the face of an incorrect/missing ID state to enable usage with low-power USB devices such as an iPhone), and initializes as such … which may include limiting the output of the DAC or amp stages themselves.

And that incorrect negotiation and identification can happen variably based on the exact configuration of the cable (which means different results from different cables) or the ID state resistance that winds up getting reported.


*The iPhone, for example, restricts power available to USB peripherals to much lower levels than many devices. And the iPhone will actively kill the connection if any device exceeds the rated power draw (you even get a message that it’s done it). So, a “low power” default can help here, even if it then (sometimes inadvertently) also reduces the operating power modes of the DAC or amp.

9 Likes

So, I have an update on the situation although I still don’t have any idea why or what may have caused the issue. I am not sure if the “correctly default the DAC’s configuration” that @Torq mentioned may have anything to with this, or if it is just black magic, but here is what happened.

First, let me point out that the DAC/Amp in question is the Hifiman EF400. The reason I didn’t mention the model previously is because I prefer to investigate possible user errors before anyone reaching the conclusion that the device is faulty (which is something that can happen quite quickly in the case of HFM products :wink: ). If it had indeed turned out to be an equipment malfunction (which it possibly was, then I would have still mentioned the model, just waiting until it was confirmed.

The model is actually quite important here because the EF400 has two USB inputs, one USB-B and one USB-C, which do not have a way of selecting between them. I don’t know how the internals deal with this, nor what would happen if both were connected at once. I haven’t tried connecting both at once, in my mind I don’t think it would be a good idea but there is no huge warning sticker to not do so, so maybe it has some kind of internal protection?

Anyway, as a quick recap, I had previously tried 15 cables, 3 of which were USB-C and the rest USB-B. With the vast majority of them (10x USB-B and the 3x USB-C) the output of both the headphone and DAC was ridiculously low. With the remaining 2x USB-B cables, which so happened to be Topping cables that came with DACs, the output was more powerful but still not powerful enough, I could still max the HD6XX without it becomeing painful (not comfortable but certainly no deafening).

So, this weekend I got another bunch of USB cables, of both the USB-B and C type. I started going through a couple of the USB-B cables first and the output was the same as with the 2x Topping cables. I then tried a USB-C cable, same story, and then I tried the USB-C cable that I use for charging and data transfer for my phone.

With this USB-C cable, suddenly everything was louder and I found that I could no longer max out the HD6XX, bringing my usual listening levels to around 9 o’clock on the dial rather than 1 o’clock that I had been experiencing.

So I had found a cable that worked. I then moved onto another cable, same result, everything was fine and at levels I expected. I then tried another USB-B cable and again, everything worked fine.

I decided to switch back to the ones that had been giving me issues and for some magic reason, everything sounded fine with them also. None of the cables that had been giving me lower outputs continued to do so :man_shrugging:

As I had been doing all these tests with my laptop, from Foobar, I decided to go back to other sources and with all of them (PC’s, Android’s, Pi4) the output is now fine, with all the cables, including the ones I had issues with before.

As I said, I have absolutely no idea what happened and the only thing I can think of is that it could be realted to what @Torq was metioning, that the DAC had somehow got “stuck” in a state that was limiting the output, and that the cable from my phone somehow got it out of that state. I don’t even know if this is possible, I just can’t think of any other possibilities and I have been trying for the past 4 or 5 hours to recreate the issue I had previously without managing to do so.

I am very happy that this is resolved and I can now get on with actually reviewing the EF400 as I really like the way it sounds and now it performs as it should.

Thanks to you all for your input!!

8 Likes

Perhaps the USB-C from your phone is an older OTG (On The Go) cable, and that is what was needed to unstick your device. Just a random thought.

1 Like

My old FiiO Q5 mobile DAC/amp has some monkey business going on with its USB implementation. It has two ports, one on the system chassis and one on the interchangeable amp unit. These have different properties, and one port will work with X while another port will work with Y. They recommend using their own vendor branded USB cable (e.g., extra, nonstandard lines). You can charge in this port, but not in that one. You can update the ROM here but not there. Etc.

It seems some vendors are extending USB in proprietary ways, and perhaps not performing adequate testing. This has happened with computers and other forms of engineering the past.

When in doubt, stay in their walled garden or reset.

That was good work being persistent and reaching a positive outcome.

USB-B has only 4 wires where USB-C can have 12 so there’s a lot of room for the device to respond to different electrical connections.

I’d vote for Torq’s idea that the device is doing some config based on what it thinks is plugged into it.

Would probably make more sense if the device was consistent and if Hifiman documented the process, but glad you got it going.

If you are up for the punishment you could see if the device as a factory reset option and see what happens after the reset.

Recently I’ve bought both the Sabaj a20d 2022 and a FiiO K9 Pro ESS integrated DAC/AMPs. I have USB wires and adapters to connect either to USB 3/Thunderbolt 4 on my Macbook Pro 14.

The FiiO uses the rather archaic USB-B connector. The Sabaj, a poorly implemented USB-3
BOTH have optical and coax cables.

QUESTIONS:

  1. Would I be better off using optical?
  2. Would I be better off using coax?
    and
  3. If YES to either of the above, what’s the best way to get optical or coax out of the MacBook Pro 14, which has USB-C type ports supporting Thunderbolt4/USB4?

The COAX S/PDIF interface on the Sabaj A20d is cleaner than it’s USB input (though even the USB input’s “issues” are well below even potentially audible levels). For sample rates no higher than 192 kHz, it’s TOSLINK S/PDIF interface is probably cleaner as well … assuming a proper cable and no pathological twists and turns in it.

Whether either is “better” will be very much dependent on the source S/PDIF device, as with S/PDIF the source owns the clock rather than the DAC owning it. A poor S/PDIF source could easily bugger things up.

A decent option (haven’t measured it for jitter yet, but it has been working fine for me for months and uses the same clock circuit as SMSLs M500 MKII, which has excellent S/PDIF jitter performance) for getting both TOSLINK and COAX S/PDIF out of a USB-C Mac would be the SMSL PO100.

Works fine with M1/M2 based machines, no drivers, no fuss, has USB-C input, and supports up to 192 kHz and DSD64 (via DoP).

3 Likes

That’s even cheap. I was looking at thunderbolt dock possibilities, and this came up

but I don’t see where the coax connector is and it’s way more expensive. I don’t really mind having all the other outputs, but it’s buying a swiss army knife when you just need a sharp blade.

The OWC Thunderbolt Dock 3 doesn’t have COAX S/PDIF, just TOSLINK S/PDIF.

S/PDIF is a signaling protocol (derived from AES3), and doesn’t dictate a specific interface. So, you have to check to see how it is being exposed. Most hubs/docks are TOSLINK S/PDIF only.

1 Like

Yes, that is wat I was just explaining to OWC chat support. I ordered the SMSL unit and will try it out.

I keep meaning to pick one (or a couple) of those up to try out to give me a nice portable S/PDIF output for my phone’s and DAPs etc.

I currently have s few D10 and D10S that I use for PC’s and this would be a great compact version, possibly even improvement?

Good day to you. I accidentally bumped into this topic of yours. May I check with you which method and equipment were used to conduct those tests. Many thanks and best regards.

Multiple test methods, including stock test options in the tooling that comes with various USB and other protocol/wireline analyzers.

In general, long-running series of predictable sample data (e.g. generated via Mersenne Twister, with common seeds on both TX and RX ends), with live and log-file comparisons.

Test gear included Beagle (and other) USB Analyzers (not at my lab to look at the model number, but its the TOTL model, and runs about $5K I think), some custom setup on a ~$1M LeCroy DSO (fastest DSO you can buy, and massive overkill for this sort of thing … but no reason not to use it), some custom software/scripts I put together, as well as cascaded high-sample-rate discrete signal samplers.

2 Likes