• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Wiim Pro distortion on spdif input

VintageFlanker

Major Contributor
Forum Donor
Joined
Sep 20, 2018
Messages
4,943
Likes
19,698
Location
Paris
It’s the Wiim.

They offer the input. Not except when it’s a TV.
WiiM Pro works 100% flawless when fed by toslink out my LG OLED C2 TV.

That wasn't the case at all with a 400€ Topping E70, that has to be updated to fix skipping issues by DPLL settings (and as such increasing Jitter by quite a margin)...
 

morillon

Major Contributor
Joined
Apr 19, 2022
Messages
1,337
Likes
264
I would guess it just uses the incoming clock recovered from the spdif transmission, that's why issues can happen when jitter is too high for example.
will be added the high jitter of the mini for example...
(but the pro concerned with the digital input is much cleaner)
;-)
 
Last edited:

morillon

Major Contributor
Joined
Apr 19, 2022
Messages
1,337
Likes
264
I won't be surprised that Wiim hasn't implemented any security reclocking - input precaution..."for help"
in somes situations not work well
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
I won't be surprised that Wiim hasn't implemented any security reclocking - input precaution..."for help"
in somes situations not work well
I doubt it reclocks the input, but I will probably see if it happens as it should deliver similar amount of jitter to the one with Pro alone.
On the other side any jitter suppression made with PLL with affect a result, so I will choose another way - samples counting :)
 

morillon

Major Contributor
Joined
Apr 19, 2022
Messages
1,337
Likes
264
would be nice to have a more degraded source than the mini...
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
I would guess it just uses the incoming clock recovered from the spdif transmission, that's why issues can happen when jitter is too high for example.
I do not think the symptoms could be caused by jitter in the incoming SPDIF. Why would it take so long to appear?

A98 module https://fccid.io/2ANOG-A98XX/User-Manual/user-manual-4402900.pdf

Does the incoming SPDIF signal go through the streamer SoC (some DSP etc. applied), or could it be bypassing the CPU, with the SPDIF I2S signal connected directly to the DAC? IMO it goes through the SoC as it offers some equalization and WiiM Pro release notes https://wiimhome.com/releaseNote suggest so.

Actually the release notes mention increasing SPDIF input latency from 20ms to 50ms in the latest firmware.

My 2 cents (just guessing): the SPDF receiver I2S (master) goes to one of the two A98 I2S interfaces (slave). An I2S DAC (slave) is connected to the second A98 I2S (master), using clocks generated by the SoC. The DSP SW does not implement any adaptive resampling or the resampling does not work reliably, and the internal software buffers in the SoC over/underflow after some time. The time depends on how much the SPDIF and SoC clocks deviate (every device is different). The firmware fix could have just increased the SPDIF input alsa buffer (the device runs linux (maybe android) -> alsa sound framework), or maybe tweaked some adaptive resampling parameters if applicable.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
I do not think the symptoms could be caused by jitter in the incoming SPDIF. Why would it take so long to appear?

A98 module https://fccid.io/2ANOG-A98XX/User-Manual/user-manual-4402900.pdf

Does the incoming SPDIF signal go through the streamer SoC (some DSP etc. applied), or could it be bypassing the CPU, with the SPDIF I2S signal connected directly to the DAC? IMO it goes through the SoC as it offers some equalization and WiiM Pro release notes https://wiimhome.com/releaseNote suggest so.

Actually the release notes mention increasing SPDIF input latency from 20ms to 50ms in the latest firmware.

My 2 cents (just guessing): the SPDF receiver I2S (master) goes to one of the two A98 I2S interfaces (slave). An I2S DAC (slave) is connected to the second A98 I2S (master), using clocks generated by the SoC. The DSP SW does not implement any adaptive resampling or the resampling does not work reliably, and the internal software buffers in the SoC over/underflow after some time. The time depends on how much the SPDIF and SoC clocks deviate (every device is different). The firmware fix could have just increased the SPDIF input alsa buffer (the device runs linux (maybe android) -> alsa sound framework), or maybe tweaked some adaptive resampling parameters if applicable.
Your assumption is wrong - they announced latency decrease to 50 ms from 80-85 ms.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Your assumption is wrong - they announced latency decrease to 50 ms from 80-85 ms.
I am only basing my assumption on
1677761589611.png

vs

1677761623773.png


It's a black box, you have to ask the vendor for true details. Actually they should be handling the problem discussed here, not local users who have no access to the device details.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
I am only basing my assumption on
View attachment 268760
vs

View attachment 268761

It's a black box, you have to ask the vendor for true details. Actually they should be handling the problem discussed here, not local users who have no access to the device details.
I understand this but you simply use incorrect data for your assumption. I've measured the latency before the latest FW releases and it was around 80 ms. No reason of course to trust me but Linkplay support itself admitted it's 85 ms after I published my findings.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
I am not arguing with you, I do not have the device. I am just trying to reason out the cause. IMO it is not jitter in the SPDIF signal. You have to ask the vendor for the issue resolution as only they have access to their firmware and know their device internals. If you had a problem with an open source streamer like moode or volumio we could troubleshoot, not in this case. But I am not saying WiiM should open source their firmware, absolutely not, I saying that just for comparison of your/our options.

While doing so you can ask them how they handle the incoming SPDIF clock domain.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
I do not even know if spdif-in issue still exists as some users reported recently that it seems to be fixed.
Sure I can ask Linkplay regarding spdif clock implementation but I have much more fun when I can find out some details myself as long as possible.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
Pro does not modify audio data that comes from spdif in. And the incoming stream seems to be reclocked to the Pro's clock.

 

morillon

Major Contributor
Joined
Apr 19, 2022
Messages
1,337
Likes
264
good news..
( and thank you)
can be precisely the effort made on this latest firmware .. "for the pops ...." (?)
;-)
hoping that solves the worries of jvn01...(?)
 
Last edited:

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Pro does not modify audio data that comes from spdif in. And the incoming stream seems to be reclocked to the Pro's clock.

There is technically no way to permanently align a bitstream clocked by a clock A to an independenty-running clock B, without any changes to the samples. Either the samples are continually resampled (i.e. new samples at clock-B intervals being re-calculated) between the two clock domains (asynchronous/adaptive resampling, ASRC) done in HW - e.g. SRC4382 or ASRC part of ESS DAC chips, or in SW - camilladsp rate-adjust, pulseaudio module combine, etc., or by using a typically long-latency FIFO and dropping excessive/adding missing samples which will eventually always happen in finite time. In both cases the audio data stream ends up modified. If no measures are taken, dropouts will inevitably occur, again modifying the bitstream. The time between dropouts/corrective actions depends on the FIFO size and pace difference of the two clocks, but the time is finite.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
There is technically no way to permanently align a bitstream clocked by a clock A to an independenty-running clock B, without any changes to the samples. Either the samples are continually resampled (i.e. new samples at clock-B intervals being re-calculated) between the two clock domains (asynchronous/adaptive resampling, ASRC) done in HW - e.g. SRC4382 or ASRC part of ESS DAC chips, or in SW - camilladsp rate-adjust, pulseaudio module combine, etc., or by using a typically long-latency FIFO and dropping excessive/adding missing samples which will eventually always happen in finite time. In both cases the audio data stream ends up modified. If no measures are taken, dropouts will inevitably occur, again modifying the bitstream. The time between dropouts/corrective actions depends on the FIFO size and pace difference of the two clocks, but the time is finite.
Are you trying to tell that spdif stream received by RME ADI-2, then reclocked, passed through USB and finally captured on the PC over USB will result in the audio data different than the source?
Audio data received over spdif from the Mini and from the Pro on ASRC enabled DAC will have different length, which is quite obvious as clocks differ. When spdif stream is reclocked it will result in the length the same as it would come directly from the reclocking device. When such stream is received by the DAC which locks to the incoming clock and passes the audio data over USB, I shouldn't be able to receive exactly the same bit-perfect audio data, according to what you've written above. But the data is in fact unaltered and the same as the source.
 

antcollinet

Master Contributor
Joined
Sep 4, 2021
Messages
7,414
Likes
12,301
Location
UK/Cheshire
Are you trying to tell that spdif stream received by RME ADI-2, then reclocked, passed through USB and finally captured on the PC over USB will result in the audio data different than the source?
Audio data received over spdif from the Mini and from the Pro on ASRC enabled DAC will have different length, which is quite obvious as clocks differ. When spdif stream is reclocked it will result in the length the same as it would come directly from the reclocking device. When such stream is received by the DAC which locks to the incoming clock and passes the audio data over USB, I shouldn't be able to receive exactly the same bit-perfect audio data, according to what you've written above. But the data is in fact unaltered and the same as the source.
How can it be bit perfect if you've resampled.

If you resample, you are calculating the values of the signal at different sample positions in the waveform (to align with the second clock), and then using these different values in the resampled bit stream. This must result in different bits.

Of course - if it is done competently it should have no audible impact on the sound.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
How can it be bit perfect if you've resampled.

If you resample, you are calculating the values of the signal at different sample positions in the waveform (to align with the second clock), and then using these different values in the resampled bit stream. This must result in different bits.

Of course - if it is done competently it should have no audible impact on the sound.
It's not bit-perfect if ASRC is in action, but ADI-2 is not an ASRC DAC and therefore it's capable to deliver bit-perfect audio data over usb and captured from spdif stream.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Are you trying to tell that spdif stream received by RME ADI-2, then reclocked, passed through USB and finally captured on the PC over USB will result in the audio data different than the source?

First please explain exactly what you mean by "reclocking" in your case.

If you capture an incoming SPDIF stream via USB asynchronous (which is the case for the RME soundcard), there are not two clock domains involved. The stream preserves the pace of the original incoming SPDIF clock.

Audio data received over spdif from the Mini and from the Pro on ASRC enabled DAC will have different length, which is quite obvious as clocks differ. When spdif stream is reclocked it will result in the length the same as it would come directly from the reclocking device. When such stream is received by the DAC which locks to the incoming clock and passes the audio data over USB, I shouldn't be able to receive exactly the same bit-perfect audio data, according to what you've written above. But the data is in fact unaltered and the same as the source.
I am afraid I do not understand your post. How can a DAC receive SPDIF and send it to PC? DAC means digital-audio converter, it has nothing to do with SPDIF.

If by DAC you call an "audio device with digital input and output", then the part "which locks to the incoming clock" is important - again no two clock domains, only the incoming clock.

I have repeatedly emphasized the "two independently running clocks" scenario. That is when the DAC part of the chain has its own clock and is not clocked by clock recovered from the incoming SPDIF stream. Since the WiiM device does not require to have the SPDIF feed as a master, it must have some other clock for the DAC part (either independent by the DAC or generated by the A113X SoC). For the DAC part to be clocked by the SPDIF clock, it would have to include a clock switch. Which it may or may not do/have, I do not know.
 
Top Bottom