Format Detection issue with W4S Recovery + Pulse XFi[Solved]

Problem here is 1.2 build does not detect my DAC (LH Labs Pulse X infinity) properly - it only sees PCM up to 96k and no DSD support. This was working fine in the earlier build.

I’m pretty sure it’s because I am using a W4S Recovery (USB regeneration device); i.e., it’s not “seeing” the DAC properly, just a generic USB device - again, this was working properly in the latest version prior to 1.2.

Substituted an UpTone Audio Regen in place of the Recovery, and it works fine - it’s only the W4S that is causing the issue, apparently :confused:

Is this with Windows/WASAPI or using one of the other playback methods?

Pulse is connected via USB to my MacBook Pro, which his running as a Roon remote.

Mac OS X 10.11.4, exclusive mode, integer mode enabled.

Beginning in 1.2, we ask the driver/device to tell us what formats it supports instead of just trying to shove content down its throat and guessing about the needed conversions until we get a “hit”.

It lets us do a better job at designing the signal path when conversions are necessary, and will enable us to make better choices as we introduce DSP features in the future.

We’ve seen some lying devices/drivers on Windows, but never on a Mac before (on Windows we have a setting to work around the issue, which is why I asked about WASAPI).

This USB re-clocker thing seems like it may be breaking some of the rules–i.e. not asking the DAC “what formats do you support” then passing that information along to the Mac accurately. We are going to try to get our hands on one and debug.

In the mean time, @mike, it would be good to see the logs from this device in case something obvious sticks out in what it’s reporting.

Hey @jhwalker, would you mind to share your Roon logs?Please, check your PM for more details. Thanks

Done - thanks for taking a look.

Looked at the logs…it’s really strange. I see the raw format support results coming from CoreAudio in the logs–and sometimes it’s only up to 96k, and sometimes 384k.

Even stranger–

When it comes up as 96k, it uses the USB Device identifier is 2522:000a
When it comes up as 384k, it uses the USB Device identifier is 2522:0009

We spoke to W4S today, and they were really surprised, explaining that their device is just a USB hub and should not be involved in these sort of shenanigans. LH Labs tells us that 2522:0009 is the correct identifier for this device, which makes sense given that that’s the one that works right.

Here’s two theories. Pick your favorite :slight_smile:

  • Something particular to the W4S device is causing the LH Labs DAC to flake out while establishing a USB 2.0 connection, so it’s coming up as a USB 1.1 device. 96k is the limit for the old USB Audio standard.

  • There is another thing on my mind, too: The LH Pulse DACs have a bug where sometimes the device gets into a really messed up state until you power cycle it. During this time, lots of things don’t work right, and you literally have to switch the main switch on the DAC off and on before things get better. Unplugging/plugging USB doesn’t help. Maybe you were in that state last night.

I’m not sure which it is, or both, or neither. Based on what I see in the logs, I’m having a hard time seeing what we could be doing wrong–that shifting USB ID for the device points in a different direction.

I should add that this problem might have been difficult to notice in previous Roon since older Roon versions didn’t include the display of supported formats, so there’s a possibility that this was happening from time to time before without throwing up any flags.

Thank you so much for taking a look. I tend to think your first theory is the correct one :wink: since I rebooted the DAC several times during troubleshooting.

What I’ve observed in the past is it does sometimes show up as a 1.1 device if the USB connection gets into a “flaky” state (very technical, right?) but again, in the past, disconnecting the USB cable, turning off the DAC, turning it back on, and reconnecting the cable has invariably fixed the issue. My concern was even that level of disruption was not “fixing” anything Day 1. Since then, though, I’ve seen pretty consistent performance (i.e., working properly).

If the Recovery didn’t sound so darn good, I’d take it out of the chain; unfortunately, the difference without it in the chain is pretty stark - you don’t know what you had until it’s gone :wink:

In any case, sounds like you did your due diligence and it’s something at my end messing things up. Please consider this one closed unless others report it, as well.