• 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

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
I haven't seen any signs of resampling in the scenario "playback is slower than capture" so I guess it doesn't happen also when "playback is faster than capture".
From my understanding a latency can be kept relatively low in the "playback is slower" case as no prefetch is needed and buffering is to provide as much time as possible without playback interruption while audio data is unaltered. The second case requires some prefetching to keep the playback uninterrupted without missing samples, so it's a compromise between the latency and playback stuttering frequency. That would explain why some users reported relatively high latencies, and others reported no serious issue here.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
From my understanding a latency can be kept relatively low in the "playback is slower" case as no prefetch is needed and buffering is to provide as much time as possible without playback interruption while audio data is unaltered.
In that case latency will keep growing, along with the buffer fill level. Eventually the buffer will overflow.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
In that case latency will keep growing, along with the buffer fill level. Eventually the buffer will overflow.
Right.


So the decision to use internal clock for spdif in-out transfer instead of incoming clock seems to be wrong for the most probable scenario, which is a TV connection.
 
Last edited:

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Yes, using one master clock for the whole chain allows to minimize latency because adaptive resampling in SW always introduces some extra latency.

Let me give an example of a design which I do not find logical. A few major vendors of RPi audio hats are marketing I2S reclocking FIFOs with perfect external clock. Of course all the issues we have been analyzing here apply. If those excellent external clocks were used for slaving the RPi I2S output instead, no FIFO would be required, no extra latency. Actually I have never seen any RPi external hat which outputs perfect master-mode I2S with RPi I2S slaved to excellent clock generator. RPi itself generates an extremely poor audio clock (e.g. https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/ ), yet all the commercial FIFO hats I know about just "reclock" that extremely-jittery signal, with all the ugly effects. Instead of using the I2S controller slave features to generate the signal synchronous to the excellent clock directly.

I think I know the reason - it would require re-configuring the linux I2S driver which most of the HW vendors do not want to delve into. But technically those devices tackle the problem in a very suboptimal way, IMO.

As of WiiM - I do not know for sure if what we are discussing here really is the case with them, there is no public information available. That's why I proposed to ask the vendor directly.
 
Last edited:

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
Yes, using one master clock for the whole chain allows to minimize latency because adaptive resampling in SW always introduces some extra latency.

Let me give an example of a design which I do not find logical. A few major vendors of RPi audio hats are marketing I2S reclocking FIFOs with perfect external clock. Of course all the issues we have been analyzing here apply. If those excellent external clocks were used for slaving the RPi I2S output instead, no FIFO would be required, no extra latency. Actually I have never seen any RPi external hat which outputs perfect master-mode I2S with RPi I2S slaved to excellent clock generator. RPi itself generates an extremely poor audio clock (e.g. https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/ ), yet all the commercial FIFO hats I know about just "reclock" that extremely-jittery signal, with all the ugly effects. Instead of using the I2S controller slave features to generate the signal synchronous to the excellent clock directly.

I think I know the reason - it would require re-configuring the linux I2S driver which most of the HW vendors do not want to delve into. But technically those devices tackle the problem in a very suboptimal way, IMO.

As of WiiM - I do not know for sure if what we are discussing here really is the case with them, there is no public information available. That's why I proposed to ask the vendor directly.
I'll probably ask them as you suggest, but in my experience it's more worthwhile to ask and confront them with some findings and investigation than just asking.
Thx for the example you've provided.
 

antcollinet

Master Contributor
Joined
Sep 4, 2021
Messages
7,409
Likes
12,294
Location
UK/Cheshire
The smaller the buffer, the smaller the latency and
  • the higher the chances of buffer issues for single-clock + PC processing
  • or the shorter the intervals (100% certainty) between buffer issues for two clock domains without adaptive resampling.

A typical chain would be:

alsa capture device -> capture buffer (CB) -> DSP (one or more threads) -> playback buffer (PB) -> alsa playback device

My 2 cents the WiiM devices have the same architecture, as it's pretty much the only logical setup in linux.

It's important to keep in mind that alsa device sets the pace of the client processing, be it capture or playback. The kernel driver wakes up to user-space process when fresh samples are available for reading by the userspace (capture) or when output buffer has gained enough room for new samples to be written by the userspace (playback).

For analog input, the capture device (ADC) and playback device (DAC or SPDIF out) are clocked by same clock. Low-cost devices use clock signals generated by internal PLLs of the SoC (i.e. the SoC I2S interfaces run in master mode), more expensive devices have external clock circuits, running the SoC I2S interfaces in slave mode.

If I were to design a low-cost device with that linkplay A98 module which has two I2S interfaces, I would probably do:

  • ADC as slave -> I2S_A input (alsa capture device A) as master
  • I2S_A (alsa playback device A) output as master -> DAC slave/SPDIF_OUT as slave
  • SPDIF_IN as master (SPDIF stream always carries master clock) -> I2S_B input (alsa capture device B) as slave
This setup does not need any external clock, no clock switching.

Now for analog input -> DSP -> output there is only one clock involved (the I2S master clock generated by the SoC), both alsa capture and playback devices A (clocked by the same clock) produce/consume samples at the same rate, buffers CB and PB are happy and can be kept quite small.

When switching from the ADC analog input to SPDIF the DSP must start capturing from the SPDIF capture device B, clocked by the SPDIF clock entering I2S_B. In this case the two alsa devices will not run at the same speed, the SPDIF_IN capture device will provide data at a different rate than the playback device will consume, and buffers CB and PB will eventually start having issues.

Typically the processing chains are pulled, i.e. it's the playback device which sets pace of the whole DSP. If so, then:
  • if playback is faster than capture, CB will eventually underflow (missing capture samples)
  • if playback is slower than capture, CB will eventually overflow (dropped capture samples)
To avoid that, e.g. CamillaDSP puts an adaptive resampler between CB and the DSP thread, which consumes samples at rate of the capture device B, and produces samples at rate of the playback device A. Of course determining the correct current resampling ratio is crucial and not simple, especially if the overall latency is to be small, i.e. buffers must be kept small and the extra room in CB for compensating the rate inequality is thus small.

Typically CB and PB work together, because DSP has a separate thread and delays on capture (DSP waiting for new samples to process) will delay delivery of DSP'd samples to playback too.

Due to the chunked processing these computer-based chains are quite difficult to tune right and to run reliably at very small latencies. Therefore HW DSP with dedicated HW which processes samples continuously (not in chunks) is much more robust and capable of smaller latencies.
Don't these types of devices use a PLL to sync the internal processing clock to the incoming data stream - like many DAC's do?

If not, why not. I'd have thought this (or ASRC - but this can't be bitperfect for those who worry about such things) are the only solutions that would make any sense.
 

napfkuchen

Active Member
Joined
Mar 9, 2022
Messages
295
Likes
397
Location
Germany
Seems like that problem
Now, every 30 min or so, the sound quality starts to deteriorate over several seconds (firstly becomes more sibilant, then noticeably slightly distorted, but less distorted than before) but now it just mutes completely for a couple of seconds before coming good again for the next 30 minutes or so. It's almost as if the Wiim is drifting out of sync with the spdif input, detecting it and then soft muting for a couple of seconds while it restarts/relocks and then unmutes.
Same behavior here, have a look / listen:


(btw: the click-sounds in the beginning are me using the computer-mouse, no issues until the LED lights up red)

signal chain:
Computer: USB
Douk Audio U2 USB soundcard: SPDIF out
Wiim pro: SPDIF in / Coax out
Genelec 8331: AES in via Neutrik 75 Ohm / 110 Ohm adapter

Wiim Pro firmware is 4.8.509547 (build date 20230302)
Seems like the issue is still not fixed.

The Wiim Pro replaces a Yamaha WXC-50 which worked flawlessly. Wiim also seems to cut the signal when source is changed (speaker LED will light up red briefly just like shown above). Apart from spotify connect ability and other app features I'm not impressed with the new device so far.:(
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Don't these types of devices use a PLL to sync the internal processing clock to the incoming data stream - like many DAC's do?

What counts are input and output I2S clocks. The CPU DSP clock is irrelevant. If the DSP consumes/produces samples in a timely manner, the DMA buffers at each side make the exact time of data consumption/delivery by the CPU irrelevant.

It's up to the vendor to design their I2S clocking. If the output is fine with I2S only (i.e. no master clock, only bitclock), e.g. SPDIF output or a DAC with MCLK PLLed from the bitclock, then you can just use the I2S clocks generated by SPDIF-in for the output I2S (provided it runs with the same samplerate). Some SPDIF receivers generate a high-speed master clock signal from the incoming stream (via PLL) which can be used as master clock for the output. Often SoCs offer clock dividers for their I2S peripherals with external inputs, these could be used. PLLs in SoCs require (what I have seen) high-frequency inputs, I2S bitclock from the SPDIF receiver is too slow as their input.

Often a SoC would have the facility, but the integration board does not offer the correct pins in its perimeter interface. The A113X SoC may offer the facility (I could not find any technical docs for that SoC), but the A98 module may not provide access to those pins.
I'd have thought this (or ASRC - but this can't be bitperfect for those who worry about such things) are the only solutions that would make any sense.

Yes that's true, IMO. Either slaving the whole chain to a single master clock, or ASRC (HW or SW-based => latency).
 
Last edited:

antcollinet

Master Contributor
Joined
Sep 4, 2021
Messages
7,409
Likes
12,294
Location
UK/Cheshire
What counts are input and output I2S clocks. The CPU DSP clock is irrelevant. If the DSP consumes/produces samples in a timely manner, the DMA buffers at each side make the exact time of data consumption/delivery by the CPU irrelevant.

It's up to the vendor to design their I2S clocking. If the output is fine with I2S only (i.e. no master clock, only bitclock), e.g. SPDIF output or a DAC with MCLK PLLed from the bitclock, then you can just use the I2S clocks generated by SPDIF-in for the output I2S (provided it runs with the same samplerate). Some SPDIF receivers generate a high-speed master clock signal from the incoming stream (via PLL) which can be used as master clock for the output. Often SoCs offer clock dividers for their I2S peripherals with external inputs, these could be used. PLLs in SoCs require (what I have seen) high-frequency inputs, I2S bitclock from the SPDIF receiver is too slow as their input.

Often a SoC would have the facility, but the integration board does not offer the correct pins in its perimeter interface. The A113X SoC may offer the facility (I could not find any technical docs for that SoC), but the A98 module may not provide access to those pins.


Yes that's true, IMO. Either slaving the whole chain to a single master clock, or ASRC (HW or SW-based => latency).

I'm not talking about the CPU clock but the data clocks as you've described.

Your description is what should happen - the suggestion from some of the posts up thread is that is not happening in the wiim - which then explains the periodic distortion and dropouts.
 

odessamarin

Member
Joined
Nov 19, 2018
Messages
51
Likes
24
Yes, using one master clock for the whole chain allows to minimize latency because adaptive resampling in SW always introduces some extra latency.

Let me give an example of a design which I do not find logical. A few major vendors of RPi audio hats are marketing I2S reclocking FIFOs with perfect external clock. Of course all the issues we have been analyzing here apply. If those excellent external clocks were used for slaving the RPi I2S output instead, no FIFO would be required, no extra latency. Actually I have never seen any RPi external hat which outputs perfect master-mode I2S with RPi I2S slaved to excellent clock generator. RPi itself generates an extremely poor audio clock (e.g. https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/ ), yet all the commercial FIFO hats I know about just "reclock" that extremely-jittery signal, with all the ugly effects. Instead of using the I2S controller slave features to generate the signal synchronous to the excellent clock directly.

I think I know the reason - it would require re-configuring the linux I2S driver which most of the HW vendors do not want to delve into. But technically those devices tackle the problem in a very suboptimal way, IMO.

As of WiiM - I do not know for sure if what we are discussing here really is the case with them, there is no public information available. That's why I proposed to ask the vendor directly.

I don't really get you here... From my point, FIFO recloker is more logical then anything. It completely ignoring timing problem at input, building from a scratch perfect I2S with his own clocks. This approach may have buffer overflow at some point. Like once in 3-4 hours with 0.7s buffer. But it's only in non stop listening. When you change track it resetet evrytime. Never have issues with this in real. Otherwise, I don't understand what you mean.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
If latency increasing gradually to 0.7s ending with a glitch is OK for your usecase, very good for you. Also the 3-4 hours are specific to your setup, other people can easily have much shorter time, depending on the clock difference (which you cannot learn prior to getting the gear). Also some gapless CDs can easily get over 60minutes of continuous playback, giving the FIFO control logic no opportunity to recover the fifo fill without audible glitches.

Please note how many people on this forum try to run SPDIF out from their TV to a streamer with some DSP and out to their nice speakers. No way with a FIFO like that.

Technically, FIFO is not a correct solution to the problem. The fact that it works OK for many people does not make it more correct. I have yet to see a product aimed at professional audio featuring FIFO for merging clock domains. Any examples?
 

staticV3

Master Contributor
Joined
Aug 29, 2019
Messages
7,539
Likes
12,005
Please note how many people on this forum try to run SPDIF out from their TV to a streamer with some DSP and out to their nice speakers.
A streamer is for receiving audio via WiFi or Ethernet.
Certainly not for SPDIF in->DSP->Speakers.
You use a miniDSP for that purpose.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
A streamer is for receiving audio via WiFi or Ethernet.
Certainly not for SPDIF in->DSP->Speakers.
You use a miniDSP for that purpose.
Well, that use case is the focus of this whole thread about Wiim Pro equipped with SPDIF input.
 

odessamarin

Member
Joined
Nov 19, 2018
Messages
51
Likes
24
Technically, FIFO is not a correct solution to the problem.

Agree, not correct for the problem of this topic - continuous spdif stream from TV.
But to recover as perfect as possible jitter free i2s, I can't image a better solution ;)
Its not just OK, its the best one can get IMHO.
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Yes, FIFO is the ultimate short-term jitter isolation, a perfect fit for some use cases. On the other hand, look at performance of adaptive resampling in ESS DAC chips which is enabled in most devices taking first places in measurements on this forum, even in measurements where the input I2S clock is PLLed from incoming SPDIF. Properly implemented (i.e. mathematically correct) adaptive resampling has a very decent performance, does not involve any major latency, and can run continuously for unlimited time. Of course it is still affected by the input jitter, to some extent.

Still, the ultimate solution is to keep the master clock by the DAC, and slave all upstream components to that clock, eliminating any need to merge multiple clock domains. Not available in most home audio setups, but recording/processing studios have used master clocks for decades. Maybe today they do not care that much, considering the quality of available ASRC options, I do not know.
 

odessamarin

Member
Joined
Nov 19, 2018
Messages
51
Likes
24
Yes, FIFO is the ultimate short-term jitter isolation, a perfect fit for some use cases. On the other hand, look at performance of adaptive resampling in ESS DAC chips which is enabled in most devices taking first places in measurements on this forum, even in measurements where the input I2S clock is PLLed from incoming SPDIF. Properly implemented (i.e. mathematically correct) adaptive resampling has a very decent performance, does not involve any major latency, and can run continuously for unlimited time. Of course it is still affected by the input jitter, to some extent.

Still, the ultimate solution is to keep the master clock by the DAC, and slave all upstream components to that clock, eliminating any need to merge multiple clock domains. Not available in most home audio setups, but recording/processing studios have used master clocks for decades. Maybe today they do not care that much, considering the quality of available ASRC options, I do not know.
good point.
 

antcollinet

Master Contributor
Joined
Sep 4, 2021
Messages
7,409
Likes
12,294
Location
UK/Cheshire
Yes, FIFO is the ultimate short-term jitter isolation, a perfect fit for some use cases. On the other hand, look at performance of adaptive resampling in ESS DAC chips which is enabled in most devices taking first places in measurements on this forum, even in measurements where the input I2S clock is PLLed from incoming SPDIF. Properly implemented (i.e. mathematically correct) adaptive resampling has a very decent performance, does not involve any major latency, and can run continuously for unlimited time. Of course it is still affected by the input jitter, to some extent.

Still, the ultimate solution is to keep the master clock by the DAC, and slave all upstream components to that clock, eliminating any need to merge multiple clock domains. Not available in most home audio setups, but recording/processing studios have used master clocks for decades. Maybe today they do not care that much, considering the quality of available ASRC options, I do not know.
Hang on - are we saying that this is how the wiim pro is managing SPDIF clock differnce? Unsynced fifo?

It is not implementing a PLL to sync internal/ouput clock to input?

Or are we just speculating.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
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.
 

onlyoneme

Major Contributor
Joined
Jul 5, 2022
Messages
1,117
Likes
624
Location
Poland
I capture the WiiM's output on the ASRC DAC and compare number of samples for the same content being played.
 
Top Bottom