I am afraid I do not understand. A DAC plays (digital-analog converter), what is actually capturing the samples? Samples of what?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?I capture the WiiM's output on the ASRC DAC and compare number of samples for the same content being played.
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.I am afraid I do not understand. A DAC plays (digital-analog converter), what is actually capturing the samples? Samples of what?
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.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.
What happens with the buffer when the local clock is synced with the incoming one?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.
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.What happens with the buffer when the local clock is synced with the incoming one?
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.).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.
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.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.
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.This way I know when Pro uses its own clock for the incoming spdif stream and when the clock differs.
Please do you have an example of such design in HW?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.
I was talking about generic buffered PLL - I've no idea how wiim implement their particular clock sync mechanism.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
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: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.
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.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.
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.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.
I don't think I have an equipment and knowledge to capture the CLK directly, so I use my ASRC device.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?
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..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
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.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.
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...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.
This seems to suggest you think only the Wiim Pro has or is having these issues, when that's not the case.Only the wiim has a problem decoding spdif from Samsung TV..