Wiim Pro distortion on spdif input

[onlyoneme]

By the streamer, in SW, which can be impacted by the firmware update.

I think I would see results of such resampling in the FFT analysis when capturing the streamer output with a device which locks to the spdif clock, but I did not see any signs of degradation. I'm also able to capture a bit-perfect stream.

 

[onlyoneme]

Let me show something.

That's the recording I've made today using Pro's output and captured over ASRC device:

8 parts, 20 s each of them.

Below is a length comparison after aligning to the end of each part:

First row shows Pros' output when content was played directly on the Pro.
Row 2 - an output of the Pro which was fed with the same content but using its digital input. It's just a beginning of the stream. The length is exactly the same.
Row 3 - one of the parts I've mentioned before, recorded 10 minutes later. The length is exactly the same.
Row 4 - another part. It's substantially shorter.

Part 1, 7, 8 of the whole recording have the length exactly like the first row.
Part 2,3,4,5,6 are shorter and very similar in the length to the last row.

How would you explain this?

 

[BenjaminB]

You won't notice unless you disconnect all audio cables from the Yamaha and plug it into the mains then measure volts AC between the Yamaha case and mains earth. You'll prob see 115V or so. If you touch mains earth with your body and brush the side of your hand over the Yamaha case you may well feel the telltale tingle of 115v AC. If you've got the phonos already connected to downstream equipment then they will bleed the AC away to ground via the phono screen. It's when you have nothing connected and then plug phonos in (with the Yamaha powered up) the potential for sparks occurs. I actually tried to discuss the issue with Yamaha and they said it was 'normal' and denied it was a problem....

Ooops, you are perfectly right. I measured ~ 100 V (in AC mode) at the chassis. Although it was indicated that current is very low (got varying results, and could hardly feel anything while touching), this should not be there at all.
Very strange indeed that Yamaha allowed such a design to be released. Normal it is not.
Oh well, have to find out how I can ground this now.

 

[JVN01]

Ooops, you are perfectly right. I measured ~ 100 V (in AC mode) at the chassis. Although it was indicated that current is very low (got varying results, and could hardly feel anything while touching), this should not be there at all.
Very strange indeed that Yamaha allowed such a design to be released. Normal it is not.
Oh well, have to find out how I can ground this now.

Although the current is indeed low it is enough to generate sparks if you drag an earthed wire across the top of the metal case.. it's also enough to damage the input of other audio gear if you connect it "live" because the phono tip is also at 1/2mains AC potential relative to the equipment input until the phono shield connects....

But we're going off topic from the Wiim spdif distortion issue!

 

[phofman]

@onlyoneme I am sorry I do not understand. Please can you explain more?

 

[onlyoneme]

@onlyoneme I am sorry I do not understand. Please can you explain more?

Which part exactly you do not understand?

 

[phofman]

Playback/capture chains for each of the tracks, and what differences they represent.

 

[onlyoneme]

Playback/capture chains for each of the tracks, and what differences they represent.

First row in the Audacity - Pro's output captured when Pro's input wasn't used. Reference recording was looped and played directly on the Pro. All of those 8 parts are captured with the same length.
Row 2,3,4 - Pro's output captured when Pro's input was used. Reference recording was looped and played on the device connected to the Pro's input. Reference recording parts are captured with the different lengths.
Row 2 - captured at the very beginning of the stream. A length of the captured part is exactly the same as in the row 1.
Row 3,4 - captured 10 minutes later:
row 3 - length is the same as in the row 1. It's for parts 1,7,8
row 4 - length is different. It's for parts 2,3,4,5,6. They are significantly shorter.

 

[_Piotr]

I was planning to feed my LG TV's optical out into a WiiM Pro, so I can either stream music or watch TV using my speakers. Sounds like I might run into issues.

I have LG TV feeding WiiM Pro without any issues at all. My setup looks like this LG B6 -> WiiM Pro -> E50 -> PA5 -> Speakers

 

[Tangband]

I've always used the WXC-50 with my own home built DAC (although the internal DACs sound also good in their own right imo). The WXC-50 hardware is superbly implemented (good selection of inputs and outputs, quality metal case, rotary volume knob, properly implemented power on/off modes etc. The biggest weakness is the dire Musiccast app interface which is clunky and frustrating, hopeless on music search and is unreliable with device detection on network. I stuck with it for several years until the Wiim Pro arrived but with the Wiim spdif issues I'll probably go back to it until/unless Wiim can get the Wiim to play properly with real-world TVs.

One word of caution - the WXC-50 uses an on-board switch mode psu which floats the metal chassis at 1/2 AC mains potential (due to the internal mains filter capacitors connected to the chassis). This means that if you plug a phono lead from the Yamaha into another piece of equipment (eg amp or active speaker) then until the phono shield connects you are injecting 1/2 mains AC into the phono input, with potentially catastrophic results.... grounding the WXC-50 chassis with a separate ground wire solved the problem..

Is the WiiM pro better sounding If used as a digital preamp compared to the less good sound from spdif out with the Yamaha wxc50 using it in preamp mode with volume regulation ?

Vintageflankers review of WiiM pro and spdif out with volume regulation on, shows it has true 24 bit resolution.

 

[silver12]

Any solution about metalic sound. In my case, when I connect TV to my DAC is all OK. When si TV conected to Wiimpro metalic sound apears only in app (netflix, hbo...), when i watch tv is ok...(box).

 

[LtMandella]

It's most likely an inaccurate clock or severe clock drift on your TV. If you search on ASR you will find lots of threads of people complaining about changing from DAC A to DAC B has resulted in regular distortion bursts like yours from their TV via the new DAC. They assume the DAC is broken, but what's actually required is a change to the Phase-Locked Loop settings on the DAC to cope with the errored TV output. if the Wiim has a setting to change the PLL, give that a go - it should make the DAC less sensitive to the nonsense coming from the TV.

As a general rule-of-thumb (dangerous, I know), TV sound digital circuits are very cheap. If you have a problem, it's normally safe to blame the TV. Some SPDIF chips (e.g. AK) appear to be more tolerant on default settings than others. Some DACs don't offer the PLL settings and this can limit their use with some TVs.

Would using an "intermediate" s/pdif coax/toslink converter/distributor help with the bad signals from the TVs? The devices are only $25 or so. I use one for converting the coax output of my FIIO M11 ESS Plus to toslink so I can feed the toslink s/pdif input of my wiim pro.

 

[antcollinet]

Would using an "intermediate" s/pdif coax/toslink converter/distributor help with the bad signals from the TVs? The devices are only $25 or so. I use one for converting the coax output of my FIIO M11 ESS Plus to toslink so I can feed the toslink s/pdif input of my wiim pro.

Only if they re-clock. The cheap versions of these simply buffer and repeat the same signal.

Even then - if the problem is caused by the TV clock rate being out of spec (rather than having too much jitter) reclocking wouldn't help unless it was also resampled, and retransmitted with an in spec clock rate.

 

[mdsimon2]

Finally got one of these and ran some brief tests that confirm some of the clocking issues being discussed when using the TOSLINK input.

Test setup was a RME Fireface 800 being feed via a TB2/FW adapter from a 2015 MacBook pro. TOSLINK output of the RME was routed to TOSLINK input of the Wiim and TOSLINK output of Wiim was routed back to RME TOSLINK input, ADAT 1 output of the RME was also routed to ADAT 1 input of the RME to act as a clock reference. RME used it's internal clock as master. Routing matrix was set such that SPDIF output was also feed to ADAT 1 output. With this, setup ADAT 1 and TOSLINK inputs of the RME should be identical if the Wiim is not modifying the signal.

Playing a 1 kHz test tone, RME reports clock sync on both ADAT 1 and SPDIF inputs. However, when viewed with REW scope recording ADAT 1 and TOSLINK inputs of the RME, although initially stable after a few seconds you can see the traces shift a discrete amount, like the traces are shifting by one sample. This is also obvious by viewing CH1-CH2 in the scope as the overall level will shift every 10 seconds or so as a result the changing phase relationship of the traces.

I haven't listened to the thing yet to determine audibility but the measured behavior doesn't seem great.

Michael

 

[antcollinet]

Finally got one of these and ran some brief tests that confirm some of the clocking issues being discussed when using the TOSLINK input.

Test setup was a RME Fireface 800 being feed via a TB2/FW adapter from a 2015 MacBook pro. TOSLINK output of the RME was routed to TOSLINK input of the Wiim and TOSLINK output of Wiim was routed back to RME TOSLINK input, ADAT 1 output of the RME was also routed to ADAT 1 input of the RME to act as a clock reference. RME used it's internal clock as master. Routing matrix was set such that SPDIF output was also feed to ADAT 1 output. With this, setup ADAT 1 and TOSLINK inputs of the RME should be identical if the Wiim is not modifying the signal.

Playing a 1 kHz test tone, RME reports clock sync on both ADAT 1 and SPDIF inputs. However, when viewed with REW scope recording ADAT 1 and TOSLINK inputs of the RME, although initially stable after a few seconds you can see the traces shift a discrete amount, like the traces are shifting by one sample. This is also obvious by viewing CH1-CH2 in the scope as the overall level will shift every 10 seconds or so as a result the changing phase relationship of the traces.

I haven't listened to the thing yet to determine audibility but the measured behavior doesn't seem great.

Michael

Not an expert here - but wouldn't that be a likely result if (as is probable) the Wiim is re-clocking the input (ASRC), rather than syncing it's clock to the RME? Then the data rate coming back to the RME will be different to the RME's clock.

Any digital comparison then is not going to work, if the comparison is expecting syncronised clocks.

 

[onlyoneme]

It would be a comeback of the old discussion I want to avoid, but the WiiM doesn't use ASRC for its input for sure.

 

[antcollinet]

It would be a comeback of the old discussion I want to avoid, but the WiiM doesn't use ASRC for its input for sure.

So how does it work? Is it syncing it's entire audio pipeline to an SPDIF input? Or is it just not bothering with clock sync at all, and letting buffers under/over run as needed? Neither seem particularly likely.

Perhaps you can link me to the old discussion - if that was conclusive.

 

[onlyoneme]

It wasn't conclusive as it can be seen in this thread. It was based on the behavior I've seen few months ago and I couldn't understand. Maybe something has changed in the meantime but ASRC is still not involved for sure.
Maybe @mdsimon2 could investigate it deeper with his knowledge and the equipment.

 

[mdsimon2]

Not an expert here - but wouldn't that be a likely result if (as is probable) the Wiim is re-clocking the input (ASRC), rather than syncing it's clock to the RME? Then the data rate coming back to the RME will be different to the RME's clock.

Any digital comparison then is not going to work, if the comparison is expecting syncronised clocks.

I am not sure that ASRC is the culprit here. I ran a few more tests in the analog domain as it minimizes the variables with clock syncing. For these tests I used a MOTU Ultralite Mk5 as I didn't need all the digital input functionality of the RME.

Clock was set to MOTU internal clock. MOTU analog output 4 was routed to MOTU analog input 4. MOTU TOSLINK output was routed to Wiim TOSLINK input. Wiim TOSLINK output was routed to miniDSP 2x4HD TOSLINK input. I then routed the miniDSP analog output to MOTU analog input 3. On the scope, the miniDSP analog output (via the Wiim TOSLINK output) and the MOTU analog output are clearly NOT synced. I also could not use a rectangular window on the RTA due to lack of sync.

I then eliminated the Wiim from the setup and ran the TOSLINK output of the MOTU directly to the miniDSP. On the scope the analog output of the MOTU and miniDSP were now clearly synced. I was also able to use a rectangular window on the RTA.

Exploring a bit further, I added a miniDSP OpenDRC-DI between the MOTU and the miniDSP. This is a digital input / output device that has an ASRC. In this case the traces stayed synced on the scope, although they do seem to wiggle back and forth very slightly. I think the wiggle is due to the OpenDRC-DI ASRC, as the miniDSP is no longer truly clocked by the exact same clock as the MOTU. Still, the result looks very different from the results with the Wiim in the chain where the traces are rapidly moving past each other (see unsync'd example in this post as an example -> #794).

Finally I ran a test where I sent the MOTU TOSLINK output to the Wiim and routed the Wiim analog output to the MOTU analog input. In this case the MOTU analog output and the Wiim analog output are NOT synced.

In conclusion, it seems the output of the Wiim is not being clocked by the TOSLINK input, in a very different way from a device like miniDSP 2x4HD which has an ASRC prior to output.

Michael

 

[onlyoneme]

The Pro can pass RME bit perfect test when its digital input is fed with the test signal. ASRC devices can't do that.