Wiim Pro Streamer Review

Before getting off into discussion of jitter or galvanic isolation, I'm wondering if the WiiM is actually passing bit-for-bit audio or if it's munging things in any way, such as through an internal SRC/ASRC.

Regarding isolation, a lot of cheap gear doesn't use a transformer on the coaxial SPDIF output. This isn't how it should be done, but it happens, and I'm wondering if that was omitted here.

 

I suspect the reason why this setup work so well because you are pretty much taking the wiim digital output out of the equation as it is only being asked to route data to hqplayer pc which hqplayer would take care of the input buffering for further processing then reroute to network end point (transformer isolation through ethernet). Now jitter and noise is determined between your final network endpoint (a rpi4 or the fitlet3 if you fancy spf+) usb connection to the dac.

 

Sync (i2s, S/PDIF) or async (USB)? If sync, isn't it just a matter of clock/timing quality? If async, it's a harder puzzle, as the buffering and in-DAC clocks should prevent any upstream timing issues.

 

Even 'sync' transmission can be buffered. The Soekris DACs have a several ms I2S buffer as part of its reclocking scheme, and I've seen similar buffer/reclock projects on Diyaudio. I'd be shocked if higher-end commercial DACs didn't use a similar scheme.

 

Thanks, I didn't realize their buffers were that long,

 

Any oversampling DAC has a buffer in the filter at least. With a linear phase filter, the peak of the impulse isn’t coming out the DAC output until (tap count) / (oversampled rate * 2) seconds later. What makes jitter “fun” is that by that time, a bunch of newer samples have already started to influence the PLL that’s being used to drive the output clock.

In principle, a NOS R2R/multibit DAC avoids this: sample in, sample out, and no PLL required. Whether that’s how your DAC vendor implements things is a different question entirely.

 

I'm not sure @Beefy was referring to the oversampling buffer in his Soekris comment.

 

My EE training is decades past, overwritten by math and CS, but that white paper (which I had read before) would be a lot easier to follow and to believe with a few schematics. In particular, how would ground-plane noise cross a differential, transformer-isolated connection, like in Ethernet, or in isolation schemes for USB? Maybe it's just me, but EE arguments without equations, schematics, and graphs sound like continental philosophy.

 

I didn't think I was, but the conversation has got me doubting the details. The Soekris upsamples to the Mhz range internally, but I honestly don't know if the buffer is before or after this.

[EDIT] here's the blurb from Soekris:

"The music is delivered over an USB interface in both PCM and DSD formats, or by the SPDIF, AES or Toslink inputs. It is then buffered and reclocked using a precise and ultra low jitter oscillator, with the digital processing done in a programmable FPGA chip, with a set of selectable advanced digital filters and a digital volume control."

But in addition to that, there are definitely other galvanically-isolated I2S buffers available, that would/could sit before a DAC starts processing the signal. To my mind, this should make all source/transmission jitter/noise irrelevant, but there are enough people who claim to hear different transport mechanisms, that I just smile and nod.

 

How is SPDIF/AES/Toslink bufferable if they are just sending out the stream at their own pace? Won't the clock difference just accumulate over time until you have to drop a sample or two? With USB the DAC will send back a signal to tell the DDC to speed up/slow down to make sure the buffer is good. But I think with SPDIF/AES/Toslink right now the only solution to avoid breaking the audio stream is to drag/drift the DAC's variable clock to line up with the DDC clock, essentially compromising the sound quality to maintain a stable connection no?

 

Jitter in this context wouldn't be a difference in clocks, but individual samples arriving 'early' or 'late'.

Whether a difference in clocks would/could make a difference in terms of dropped samples over the length of a typical song, I'd have to do the math.

 

Async simply means the system uses its own internal clock as opposed to using the incoming clock via some PLL. I believe even in an async/buffered system the system still needs to process the incoming bitstream along with the clock, and jitter and poor incoming clock quality could still affect the bitstream as it gets bufferd. I believe this is why no matter how many times we are told the dac buffers the incoming signal and is not affected by the jitter and clock of the upstream device, we still find in real world we hear real differences between 2 different digital transports.

 

I didn’t think he was; my point was that buffers like that are fairly common for other reasons, and can easily be 10s of ms long if not longer on some DACs (Schiit and Chord notably).

That is precisely the role of a phase-locked loop: it generates a multiplied clock which is based on the averaged input clock. Without that, you’d be periodically dropping samples if the source oscillator is running faster than the internal one, or periodically having glitches/dropouts in the other case.

If you had a perfectly locked clock between sender and receiver with some random jitter inserted on the sender side, you’d only need to buffer one sample ahead unless the jitter exceeds the clock period. Where things get tricky is that your clock isn’t exactly locked, so you either have to try to recover the sender’s clock with a PLL or go through an asynchronous sample rate converter (ASRC) to account for the difference. Buffering just defers the need to drop samples or insert dummy samples, but eventually it’ll happen, and unless you drop or insert a whole buffer’s worth you’ll start having frequent dropouts as soon as that buffer under or overruns.

All of the above is why asynchronous USB audio is such a huge improvement. The downside is that isolating USB is more difficult.

 

You know, I just saw the Mercury V3 Loaner is a go, maybe for kicks, it's a good opportunity to try it for yourself and see how it measures up in your system in the grand scheme?

 

This is the step in the argument that I don't get, not in this form at least. In asynchronous comms, the source clock is irrelevant. Samples are buffered up and released at the destination clock rate. The control circuitry asks the source for more data when the buffer runs low, more are sent at whatever pace, and stored in the empty buffer slots. Here I'm talking from experience, I've written code like that, but not recently. The only way the timing of incoming samples could make a difference in a reasonably functioning system is if the electrical activity of the receiving circuit perturbs the destination clock, like the ground-plane noise mentioned indirectly earlier in the thread. But then the discussion would be about circuitry that might prevent that kind of noise -- which has nothing to do with the digital processing -- through techniques like differential transformer-coupled circuitry.

 

The more I read people debating this kinda stuff, the more I think I should take up my buddy's offer on his spare turntable and get into vinyl...




(but that's just a different flavour of crazy)

 

Why don't you write to John Swenson and ask him. You can likely get his contact info by contacting UpTone.

 

I believe unlike comm systems where asynchronous protocol is used. Almost all audio connections are not encoded like that. AES and SPDIF encode the clock with the data and the buffer has to recover the clock and buffer in the data. If you use USB then you still have a potential ground plane noise issue given no galvanic isolation is perfect even if both input and output are transformer coupled. I think if someone comes up with their own asynchronous audio transfer codec that’s transferred via st optical then we would solve the jitter and clock issue. I just don’t think there is any boutique DAC manufacturer with the budget to create their own asynchronous protocol, encoder and decoder.

These are my theories. I have no desire nor any tools to do any work to prove it one way or another.

Other audio stuff that drives EE crazy: why do different Ethernet cables sound different? Why do different network switch sound different? I don’t know they do.

I just listen to a bunch of stuff and get the one that sounds good to me

 

Putting aside that you can't isolate USB itself with a transformer, that's not how transformer-coupled isolation works. Any ground noise on the transmitter side will turn into signal noise in inverse on the receiver side. Now that's still noise coming into your system and needs to be filtered appropriately, but the whole point of transformer isolation is to isolate the ground potential between sender and receiver.

Opto-isolation doesn't completely solve this problem either. It just might filter the noise more effectively.

I don't know that they do either. Jokes aside, I have a lot easier time believing this for switches than I do cables, but without first doing an ABX and then comparing packet traces to look for retransmits or other garbage, it's hard to identify why there might be a difference. Different cables may have different inductance and capacitance, and this "might" be acting as a noise filter to some degree. Different switches can behave wildly differently with respect to fine-grained timing of packets and can inject noise of their own.

There's no magic bullet for noise other than just to filter, filter, filter. As you go up the price ladder in audio equipment, you'll find that more time, attention, and BOM cost is spent on filtering every possible source of noise and clock jitter. My belief is that this accounts for more of the differences in performance than any other kind of magic fairy dust that manufacturers claim is sprinkled in their products. A device like the WiiM Pro has just enough filtering to make the device functional and pass EMC testing. A more expensive streamer is going to have much better filtering from its power supplies and regulators all the way through to its digital outputs. You can try to filter after the fact on the receiver side, but filtering out the noise before it gets into the signal is always going to be better.

 

Kudos for having this discussion on content and without the HF flamewars.

IIRC the buffer on Soekris' units is 1 ms. Newer IanCanada FifoPi's have a programmable delay time from 0.1 to 1.0 seconds. Older ones were fixed at 700 ms I think.

^ this and it is amplified on Soekris DACs. They use a programmable oscillator, which track the input clock, so by definition their error becomes related to the input error. Measurements published on diyAudio have also shown so.

Yes, with two clocks and one running ever so slightly slower than the other, dropouts will and do occur eventually. This is another advantage of USB's isochronous operation, where the receiving end gets to pace the source.

Reading the Audiophile Style forums from time to time, I remember his argument indeed is: noise induced through ground planes.

...as well as introducing gobs of jitter.

Agreed. And yet here I am wondering where my next investment in digital should be. Going from a Raspberry Pi to an Yggdrasil+ over Unison USB today, I can't decide between:
- putting a USB isolator in between;
- switching to a Pi2AES approach;
- get a Holo Red for more than twice the cost;
- do nothing at all.