USB Nervosa Thread Decrapifiers, pro interfaces, and bears oh my

I found Yggdrasil to sound best with software upsampling to 192. The iZotope bit rate converter in Audirvana was good, but I found the newest Roon upsampler to be better. Direct mode and a few other options were also important as well. But whatever the software in use, when I had the Yggdrasil, I always wanted the 4x light lit up on its front panel.

 

I found Yggdrasil sounds preferable with a 24 bit input stream than a 16 bit one, even if the source material is 16 bit. Soundstage is wider mainly, and some slight changes to FR - maybe a bit less upward tilted.

I thought that software oversampling makes Yggdrasil a bit more laid-back, not in terms of FR but that transients are less aggressive and smoother. Haven't tried doing this in a while though - maybe I will give it another go soon...

 

I should note that Audirvana Plus 3.x seems to always send tracks to Yggdrasil at 24-bits. All is does is add zeroes for the extra bits. I am not sure how that could do anything to soundstage or change FR. Maybe someone could explain that to me.

I just changed A+ to upsample as much as it can in factors of 2. So my Red Book content is being sent to Yggdrasil at 24/176.4. I hear no real difference compared to no upsampling.

Maybe my ears aren't golden enough.

 

Exactly. At the moment I am sending at 16/44.1. The Yggdrasil A2 does a spectacular job of up-sampling. It may be true that the CPU can spend more cycles on the problem, but until someone explains why, or compares the diffs, whatever Yggdrasil is doing, I am enjoying it as is. Whatever the best solution is, Yggdrasil sounds musical. And also exactly right, since no matter what I send, it is going to up-sample to 352 or 384, I am not yet seeing a reason to up-sample on the computer first. I can't imagine the CPU solution differs by more than a bit or two anyway, well below the noise floor. I see no reason to chase ghosts that cannot be heard.

Yggdrasil is doing something I have never heard in a digital to analog converter, but whatever it is doing, it's not something any other DAC has done no matter what I set the bit-rate too before the DAC received the data.

 

With S/PDIF (both COAX and TOSLINK) and AES connections there will always be 32-bits* in the sample word. Of these, there will always be 24 bits present for sample data, regardless of the actual bit-width of each sample. Per the spec, any unused bits will be set to zero. This will happen at the S/PDIF interface with no need (and in most cases no ability) for upstream software to change it.

In all cases, the first four bits of the sample word are used for the preamble. The last four bits are used as flags to indicate validity, subcode-data, channel status and parity. And the remaining 24 bits are used for the actual sample data with either 16, 20 or 24-bits of populated data and the remainder always being zeroed.

In other words, for S/PDIF and AES connections, the DAC sees the same thing, sent the same way, regardless of what you set the bit-depth to in software.

--

*Technically this is 32 time-slots rather than "bits" in the traditional sense, though from a structural perspective the encoding is the same.

 

That is something I did not know. Great information! A+ 2.x always said it was sending the content at 16 bits when I did not choose to upsample it in software. I asked Damien about the change and he said he was sending it as 24 bit now but padding it with zeroes. I guess that was always the case since I have been using S/PDIF coax all along.

 

Amazing, thanks!

I always found it baffling that changing the bitdepth in software made a difference. From what you say, it must be correlation, not causation. I was going to run some measurements to find out what was going on and I am definitely going to do so now.

 

I figured it was just changing the load on the cpu which through some manner of power related voodoo caused a change in perceived sound.

 

Thinking about it, it's possible when I did this test previously I had ReplayGain enabled. In which case it is perfectly reasonable that 16 bit mode would sound different even if correctly dithered. I think I need to do a retrial.

 

I'm testing out the Intona as it was easily ordered on Amazon, and I rather liked that their website makes few claims that this does anything more than provide isolation. The computer finds Yggdrasil at startup every time as expected, and I've had no drop outs. I also liked the idea of not needing yet another power adapter. Anyway it has gotten rid of the slight noise I was hearing after I moved the Yggdrasil/MJ2 to another wall plug, ground loop defeated. I don't know that it sounds any better or worse than TOSLINK, but with this USB is at least equal.

 

With the UpTone Audio ISO Regen now available, I see no reason to invest in the Intona. The ISO Regen was designed specifically with audio in mind. It has better clocks and does a better job regenerating USB packets.

 

You're aware that reclocking USB audio is pure snakeoil, right?

 

Anytime a USB packets goes through an active USB hub chip they are "regenerated". Doing so with a better hub chip and better clocks is a good thing. So no, it is not "pure snake oil". Now you can argue all day long about the benefit of using better clocks in a USB active hub, but it can't be a bad thing.

Here are couple of images that are interesting:





Now, you could argue this is marketing fluff, but the difference is not insignificant. How much of that has to do with isolation and cleaner power is a good question. But the USB output is not bad at all.

 

Assuming asynchronous USB 2.0 Audio, re-clocking USB packets will have zero effect on the jitter of the sample clock. Even given a perfect USB-clock, you're still limited by the clock in the DAC that is used to pull data out of the input buffer. So if the re-clocking of the USB signal is improving things audible, it's for reasons unrelated to clocks.

USB audio isn't anything like AES (or S/PDIF), especially in regards to clocks and timing.

With asynchronous USB, packets are sent on request with the request frequency being computed based on the required sample rate. Those requests must be serviced within the request window period - BUT they can be sent ANYTIME during that window. So having a femto-second class USB clock isn't very useful when you're talking about a request window period of 125µs (High Speed USB, typical audio sample rates) - as in, it's permissible for the requested packet to be sent ANYTIME in that 125µs window.

You deal with this by having a buffer, the length of which will be twice your request window period.

Oh, and it's also worth noting that, depending on your sample rate (etc.) the actual number of samples transferred per packet can (and does) differ (with Redbook specs you'd see alternating 5 and 6 sample transfers).

The long and the short of this is that, from the DAC's perspective, even just staying at it's USB receiver, all that super-accurate re-clocking going on upstream is subject to a huge degree of variation between any two packet requests (since they can swing across both extremes of the receive window period), different numbers of samples per transfer.

Are other effects possible? Sure. But for async USB 2.0 audio, as long as data is arriving at the DAC's USB receiver fast enough not to cause drop-outs then while USB-re-clocking might improve your eye-pattern it's not influencing sample-clock jitter.

 

No, it's pure snakeoil. The USB here is asynchronous. As long as you're not getting buffer underruns (which "reclocking" won't solve), you're pretty much golden. Your USB audio doesn't actually need accurate clocks at all- it's assembled in a buffer in the receiver and clocked out from there- the clock quality of the receiver matters, taking that data out of a buffer and clocking it into the DAC proper.. after the USB connection.

Reclocking your USB audio is like sorting a load of post and then then chucking it into a big mail sack; wasted effort.

If you really care about the sound, you'll look at dropping USB completely, anyway, rather than faffing with USB widgets.

Edit: Ninjaed in some style by @Torq. Bastard.

 

I think it's time I stopped participating in this particular thread. This information is repeated at various places throughout it, and the same stuff still comes up over and over. There's only so many ways to say the same thing. None of them change the reality of how Async USB 2.0 Audio works, nor what that means in terms of the potential influence of up-stream fixes vs. internal aspects of the DAC.

At this point, my give-a-damn is broken, I've run out of fucks to give, and since it's not my money being spent on these widgets I'm not even sure why I continue even trying to address them.

 

A bit like that?

I guess the reason to keep trying is that if you don't, you get a critical mass of rando groupthink, which spreads by osmosis to some of the more established members- some of whom know analogue electronics like goddamn ninjas, but who are a bit leery of computers- and those people, at least, deserve better. Thing is, it won't just stay in this particular thread, it's very much a case of "if you tolerate this, then your children will be next".

The rot is always there- you're a lot better at pushing back against it than I am, I tend to get short-tempered, and tell people where to go, which helps no-one.

As it is, I suspect that if you hadn't been arsed to dredge your memory, winders would still be talking bilge and linking eye diagrams until he was blue in the face. I know this particular fallacy has been dispelled many, many times, even in this thread, but I suppose people don't feel like reading the whole thing, and cut'n'wasting misleading marketing material/HF is quicker and easier.

 

As I have stated multiple times, I will be dropping USB completely. I also don't feed USB to my DAC. But, many people do use USB to their DACs. Yes, way less than ideal USB packets will get to the DAC and no data will be lost. The supposition is the better the USB signal the DAC receives (including power and ground), the less the DAC's input and conversion circuitry is negatively affected by it.

My "give-a-damn" is broken too. All I was trying to do is tell someone that there is a device out there that is better than the Intona at providing isolation for audio purposes.

 

I appreciated the suggestion winders; just went this route as it was in stock, cheaper, etc.

I looked at the ISO Regen option, but after having read up on how the Asnyc protocol works (i.e., the DAC is involved in the packet rate, flow control, so yea, avoids overruns, and likewise if done well should be able to avoid underruns with some buffering and requesting more data well in advance of buffer empty), and assuming Yggdrasil is re-clocking anyway as claimed, and assuming the serial signal is not so heinous that data is corrupted... I just couldn't see how regenerating the signal can alter the sound quality (yes I am aware many people have reported it does).

The ground loop problem though, common problem fixed by breaking the loop (this being a safe way vs people who disable ground on their gear )

 

The strength of the ISO-Regen - like the name suggests - is in the ISOlation.

USB is noisy as shit. Uncertainty in the packet transfer creates noisy shit in the receiver. Bad signal integrity creates noisy shit in the receiver. That noisy shit, unless isolated from other sensitive part of the device, will have an effect.
How is that hard to picture?
Clocking is one aspect and it affects not just the timing accuracy of things, but also the noise pattern/intensity when trying to recover a jittery signal. Being packetized probably doesn't help, either.