Wiim Pro distortion on spdif input

[phofman]

I capture the WiiM's output on the ASRC DAC and compare number of samples for the same content being played.

I am afraid I do not understand. A DAC plays (digital-analog converter), what is actually capturing the samples? Samples of what?

 

[onlyoneme]

I am afraid I do not understand. A DAC plays (digital-analog converter), what is actually capturing the samples? Samples of what?

Ok, I should be more specific. My ASRC DAC can output on the usb a content from its digital input after resampling to its own clock. As the content is resampled from the external clock provided by the Pro which is connected to the DAC, I can capture it on my PC and compare number of samples recorded. Those numbers change when the incoming clock changes. Of course source content remains the same.
This way I know when Pro uses its own clock for the incoming spdif stream and when the clock differs.

 

[antcollinet]

I do not know how possible it is, but I observe a different behavior with the current FW. I've used a device with a clock faster than the WiiM's one.
At the beginning Pro sends the audio data received on its input with its own clock, so probably FIFO buffers are used as there is no sign of resampling.
After some time, about 2 min in my case, it seems to switch to the incoming clock and uses it instead for the audio data sent.

That is what I would expect with a PLL. As the buffer fills (usually to half full) the PLL won't be syncing. Once the buffer is half full the PLL will adjust the local clock to match the incoming clock to keep the buffer half full.

 

[onlyoneme]

That is what I would expect with a PLL. As the buffer fills (usually to half full) the PLL won't be syncing. Once the buffer is half full the PLL will adjust the local clock to match the incoming clock to keep the buffer half full.

What happens with the buffer when the local clock is synced with the incoming one?

 

[antcollinet]

What happens with the buffer when the local clock is synced with the incoming one?

It stays half full. If it starts to get fuller, the PLL control loop speeds up the local clock slightly to increase the clock out rate. If it starts to empty the reverse happens.

 

[phofman]

Ok, I should be more specific. My ASRC DAC can output on the usb a content from its digital input after resampling to its own clock.

OK, IMO the problem is the terminology. A DAC by its name outputs audio signal, cannot capture digital input to USB. Apparently by DAC you call your whole audio device of which a DAC is only a part (the other parts being ADC, SPDIF input, ASRC DSP etc.).

As the content is resampled from the external clock provided by the Pro which is connected to the DAC, I can capture it on my PC and compare number of samples recorded. Those numbers change when the incoming clock changes. Of course source content remains the same.

So your chain basically measures the playback time, not in absolute terms, but relative to each scenario (as the "measurement" clock for each scenario is always the same). Digital ASRC can be likened to DA -> AD conversion where the ADC is timed by the output clock.

This way I know when Pro uses its own clock for the incoming spdif stream and when the clock differs.

With ASRC you are not measuring the actual clock pace, but the pace of audio. Let's say clock CLK1 transfers a given audio fragment in time T1. If a device correctly adaptively resamples to CLK2 = 1.1xCLK1, the audio fragment will again take T1, using more samples at CLK2 speed.

You can distinguish the two cases when also capturing the CLK directly, without ASRC. But in these short measurement times (CLK1 differs very little from CLK2) you need to be precise down to single samples. How do you establish the audio fragment boundaries for each measurement?

 

[phofman]

It stays half full. If it starts to get fuller, the PLL control loop speeds up the local clock slightly to increase the clock out rate. If it starts to empty the reverse happens.

Please do you have an example of such design in HW?

That's how software ASRC works - e.g. it measures some buffer fill which gets consumed by the output clock (alsa buffer fill in CamillaDSP or alsaloop), and keeps adjusting the ratio of resampler somewhere in the chain (right after capture in CDSP) in some smooth way, to minimize output jitter. Typically it takes some trial/error and "magical" constants to fine tune to work reliably.

HW ASRC runs continuously (not in chunks like interleaved processes in an OS do) and does not need the larger buffers. IMO there is no reason for the HW ASRC to wait for 2 minutes before it starts recalculating the samples.

Now as of the Pro: My 2 cents the software update did not enable some HW feature of the device (HW PLL + clock distribution is quite expensive), but fine-tuned (or even implemented) some SW ASRC in their chain. It would also explain the behavior - the ASRC feature keeps the resampling ratio at default 1:1 for a while (basically keeping the output audio pace equal to the output clock) until it collects enough of conclusive data for smooth adjustment of the resampling ratio in the direction of the output clock (adjusting the output audio pace towards the input audio pace). Larger buffers in SW allow this longer period of adaptation.

Or maybe it's different, but again IMO the only way to avoid the speculations is to ask the vendor directly.

Edit: fixed the reasoning

 

[antcollinet]

Please do you have an example of such design in HW?

That's how software ASRC works - e.g. it measures some buffer fill which gets consumed by the output clock (alsa buffer fill in CamillaDSP or alsaloop), and keeps adjusting the ratio of resampler somewhere in the chain (right after capture in CDSP) in some smooth way, to minimize output jitter. Typically it takes some trial/error and "magical" constants to fine tune to work reliably.

HW ASRC runs continuously (not in chunks like interleaved processes in an OS do) and does not need the larger buffers. IMO there is no reason for the HW ASRC to wait for 2 minutes before it starts recalculating the samples.

Now as of the Pro: My 2 cents the software update did not enable some HW feature of the device (HW PLL + clock distribution is quite expensive), but fine-tuned (or even implemented) some SW ASRC in their chain. It would also explain the behavior - the ASRC feature keeps the resampling ratio at default 1:1 for a while (basically keeping the output audio pace equal to the output clock) until it collects enough of conclusive data for smooth adjustment of the resampling ratio in the direction of the output clock (adjusting the output audio pace towards the input audio pace). Larger buffers in SW allow this longer period of adaptation.

Or maybe it's different, but again IMO the only way to avoid the speculations is to ask the vendor directly.

Edit: fixed the reasoning

I was talking about generic buffered PLL - I've no idea how wiim implement their particular clock sync mechanism.

Generally a buffer is required for jitter reduction. If you have no buffer, then any jitter on the input has to be passed to the output. With a buffer, the output clock can be be adjusted much more slowly, to a rolling average of the input clock.

The buffer doesn't need to be anything like 2 minutes though. A few (10s of?) milliseconds should be enough.


Most of this is based on reading I did some years ago, so I've no idea how these things are implemented in detail, in current hardware. Here is an example I've found though.

Asynchronous FIFO Clock Recovery | Audiopraise

www.audiopraise.com

which is describing an FPGA library block implementing the method.

 

[phofman]

I was talking about generic buffered PLL - I've no idea how wiim implement their particular clock sync mechanism.

Generally a buffer is required for jitter reduction. If you have no buffer, then any jitter on the input has to be passed to the output. With a buffer, the output clock can be be adjusted much more slowly, to a rolling average of the input clock.

The buffer doesn't need to be anything like 2 minutes though. A few (10s of?) milliseconds should be enough.

That's one approach - tweaking the output clock and keeping the samples intact. But ASRC (both HW and SW) accepts the fixed output clock as input and recalculates the samples, to allow much shorted group delays. This is how AD1896 does it:

IMO the pictures in https://audiosciencereview.com/forum/index.php?threads/wiim-pro-streamer.39576/post-1529667 do not suggest there is any HW buffer with advanced PLL in Wiim Pro . They do not suggest any HW ASRC bypassing the SoC either - but there may be more components below the A98 module.

 

[antcollinet]

That's one approach - tweaking the output clock and keeping the samples intact. But ASRC (both HW and SW) accepts the fixed output clock as input and recalculates the samples, to allow much shorted group delays. This is how AD1896 does it:

View attachment 274583


IMO the pictures in https://audiosciencereview.com/forum/index.php?threads/wiim-pro-streamer.39576/post-1529667 do not suggest there is any HW buffer with advanced PLL in Wiim Pro . They do not suggest any HW ASRC bypassing the SoC either - but there may be more components below the A98 module.

In the diagram there is still a FIFO buffer and PLL on the input. Needed so you can store sufficient samples to calculate the actual value at any arbitrary (re) sampling point for the output. So you have a buffer in any case.

 

[phofman]

Yes, there is always a buffer, in any DSP. But new samples are calculated and the output clock is fixed, supplied to the chip externally. It's not a longer FIFO with slowly PLLing output clock to fit the incoming clock. IMO the Audiopraise approach is quite unique and I do not know of any other device using it. I have no knowledge about performance improvement compared to standard ASRC.

 

[onlyoneme]

With ASRC you are not measuring the actual clock pace, but the pace of audio. Let's say clock CLK1 transfers a given audio fragment in time T1. If a device correctly adaptively resamples to CLK2 = 1.1xCLK1, the audio fragment will again take T1, using more samples at CLK2 speed.

Yes. As CLK2 is somewhat constant here as it's the ASRC DAC clock, I'm getting different number of samples for different input clocks.

You can distinguish the two cases when also capturing the CLK directly, without ASRC. But in these short measurement times (CLK1 differs very little from CLK2) you need to be precise down to single samples. How do you establish the audio fragment boundaries for each measurement?

I don't think I have an equipment and knowledge to capture the CLK directly, so I use my ASRC device.
I compare results in the Audacity with a captured stream when "DAC" usb input was used to feed the device, in this scenario I'm getting the number of samples equal to the source, as clock remains the same. After aligning my recordings I can see differences in the sample quantities.

 

[onlyoneme]

I cannot see any signs of resampling when I analyze Pro's output transferred to my PC via toslink-to-usb converter in the FFT analyzer. It remains fully transparent.
On the other side I can see obvious jitter differences for sine 12k signal when I use the ASRC device for capturing. At the beginning it looks just like the native Pro's output. After some time it starts to look like the jitter of the device connected to the Pro's input. It can happen if Pro switches to the another input clock indeed.

What I've seen today - it's a cycle. After some time jitter looks like the Pro's one, and later like the one of the input device. And again and again.

 

[JVN01]

Hmmm well unfortunately after a month or more of satisfactory spdif behaviour (ie OK sound quality which did not deteriorate, or mute/dropout) it seems like a recent firmware update has broken it again! Now I'm getting noticeably poor/sibilant sound quality almost all the time, along with regular dropouts (muting). In fact it's worse than it ever was at the start, I'm getting dropouts every few seconds or so sometimes now. Firmware version is 4.8.511631
Very disappointed.

 

[JVN01]

Hmmm well unfortunately after a month or more of satisfactory spdif behaviour (OK sound quality which does not deteriorate, or mute/dropout) it seems like a recent firmware update has broken it again! Now I'm getting noticeably poor/sibilant sound quality almost all the time, along with regular dropouts (muting). In fact it's worse than it ever was at the start, I'm getting dropouts every few seconds or so sometimes now. Very disappointed

Never, ever had this issue using Yamaha WXC-50, either using Yamaha internal DAC or external own-built Burr-Brown 24 bit DAC. Only the wiim has a problem decoding spdif from Samsung TV..

 

[Joffy1780]

Never, ever had this issue using Yamaha WXC-50, either using Yamaha internal DAC or external own-built Burr-Brown 24 bit DAC. Only the wiim has a problem decoding spdif from Samsung TV..

It is definitely not an issue which is limited to the Wiim Pro. Out of the three devices you have, yes it is only the Wiim, but there are myriad reports of issues with spdif output from TVs with numerous DACs. At least Wiim are actively trying to solve the issues with regular firmware updates, unlike other manufacturers.

 

[JVN01]

It is definitely not an issue which is limited to the Wiim Pro. Out of the three devices you have, yes it is only the Wiim, but there are myriad reports of issues with spdif output from TVs with numerous DACs. At least Wiim are actively trying to solve the issues with regular firmware updates, unlike other manufacturers.

It is definitely not an issue which is limited to the Wiim Pro. Out of the three devices you have, yes it is only the Wiim, but there are myriad reports of issues with spdif output from TVs with numerous DACs. At least Wiim are actively trying to solve the issues with regular firmware updates, unlike other manufacturers.

I think you missed the point of my update - Wiim already appeared to have somehow fixed it, but a recent firmware update seems to have broken it to a point where it is now at least as bad (if not worse) than it was before...

 

[Joffy1780]

Only the wiim has a problem decoding spdif from Samsung TV..

This seems to suggest you think only the Wiim Pro has or is having these issues, when that's not the case.
If you raise a ticket, if you haven't already, at least Wiim are trying to rectify these problems, unlike other companies.
This was my point. Especially given this is not the primary function of the Wiim Pro whereas actual dedicated DACs have these issues and the manufacturers are not nearly as active in resolving them.

 

[zeppelin2]

@JVN01 Are you using the optical or coax out on the Wiim Pro?

I'm having similar issues with the optical out from my Samsung TV into the Wiim Pro, and then into an external DAC. The sound is sibilant and unnatural. No dropouts though.

I've found it much worse sounding when using the coax out rather than the optical out.

Hadn't noticed any issues previously when the Samsung TV was connected directly to my DAC.

I've only got a few days left in the return window, unfortunately I'm thinking I'm going to have to return it.

 

[JktHifi]

Probably the spdif input should be sealed. Should connect your TV spdif out to any other DAC/amp.

It’s quite interesting for me that the Yamaha streamer able to do it correctly because my TV HDMI out to PS4 then the PS4 spdif out to soundbar, makes bad sound compared to direct TV spdif out to the soundbar. PS4 role is almost the same as the Yamaha streamer/WIIM.