WiiM Pro no longer bit perfect?

[onlyoneme]

Difference between transport protocols? Or caching?

Simply better implementation on the WiiM? When I was performing similar tests some time ago, I haven't seen such differences between LMS and Roon.

 

[AlPo]

Wonder if there’s a measurable change in “TOSLINK in - TOSLINK/SPDIF out“ behavior with the latest firmware

 

[onlyoneme]

Wonder if there’s a measurable change in “TOSLINK in - TOSLINK/SPDIF out“ behavior with the latest firmware

I cannot tell as I do not have a device with the old FW for a direct comparison. WiiM's clock is not synced to the clock on digital input, but it fluctuates around in the stepped process. For example, with my system:

-14.4 ppm clock delta at the beginning
then a shift after 2 min 40 s
6.6 ppm after the shift
then a shift after 4 min 12 s
-5.4 ppm after the shift
then a shift after 4 min 14 s
6.6 ppm after the shift
then a shift after 4 min 13 s
-5.4 ppm after the shift
etc.

Values above are approximate.

 

[Griff]

Wonder if there’s a measurable change in “TOSLINK in - TOSLINK/SPDIF out“ behavior with the latest firmware

From a purely listening perspective, it's certainly no worse than before. Listened all morning to a ddc feeding the toslink in then toslink out and couldn't swear it's better but the fact it went all morning without fatigue is a very good sign.

 

[AlPo]

I cannot tell as I do not have a device with the old FW for a direct comparison. WiiM's clock is not synced to the clock on digital input, but it fluctuates around in the stepped process. For example, with my system:

-14.4 ppm clock delta at the beginning
then a shift after 2 min 40 s
6.6 ppm after the shift
then a shift after 4 min 12 s
-5.4 ppm after the shift
then a shift after 4 min 14 s
6.6 ppm after the shift
then a shift after 4 min 13 s
-5.4 ppm after the shift
etc.

Values above are approximate.

Interesting finding, thank you! So, am I correct assuming that the clock on WiiM’s digital out is its internal clock that is adjusted periodically when the delta reaches a certain limit in order to avoid breakups/clicks?

 

[onlyoneme]

Interesting finding, thank you! So, am I correct assuming that the clock on WiiM’s digital out is its internal clock that is adjusted periodically when the delta reaches a certain limit in order to avoid breakups/clicks?

You might be right I think. This under/overclock behavior can be a prevention against buffer under/overrun.

 

[WiiM Team]

We are currently evaluating the bit-perfect accuracy of the optical-in input source. To do this, we'll capture the audio output in a file and compare it against the original source file to verify the fidelity of the playback through the optical-in input.

 

[Brantome]

We are currently evaluating the bit-perfect accuracy of the optical-in input source. To do this, we'll capture the audio output in a file and compare it against the original source file to verify the fidelity of the playback through the optical-in input.

My reading of this thread is that it’s not really about the optical-in input source, that just happened to be the firmware change that prompted the OP to check whether his device was still bit perfect.

 

[CrystalGipsy]

Thanks. I just figured out what was happening.

If the tracks are played individually, then the bit-perfect test is ok. If all the tracks (44, 48, 88 and 96) are placed in the LMS queue and the queue is played only the 96 khz track is bit perfect.

I checked also placing in the queue my two 44khz test files - bit-perfect. Placing the 44khz file AND any other sample rate file immediately after, and the first 44khz file fails but the second is ok.

This was not the case before, but so be it. An album always has the same sample rate so not a problem, for me at least. If you add to your playback queue albums with multiple sample rates, some form of resampling may be going on...

I have lots of albums of mixed sample rates and many albums released on streaming do, so this is not something that should be happening.

 

[onlyoneme]

My reading of this thread is that it’s not really about the optical-in input source, that just happened to be the firmware change that prompted the OP to check whether his device was still bit perfect.

Yes, the issue mentioned here is related to squeezelite client behavior on the WiiM. It's not related to the toslink input.

But in the meantime I've tested 3 different scenarios in the digital domain when the WiiM is fed via its toslink input, to verify bit perfectness of the stream over toslink output. I've used 16 minutes file at 48 kHz as my source stream to compare it with the captured file.

Case 1 - the Pro is fed with the stream clocked at X, the Pro uses its own clock Y, the receiver gets the stream and synchronize to clock X
No chance for being bit-perfect because the number of received samples will differ from the source as long as X != Y. This case is very unlikely to happen in real life.

Case 2 - the Pro is fed with the stream clocked at X which is synced with the Pro clock, the Pro uses its own clock Y, the receiver gets the stream and synchronize to clock X
Bit-perfect scenario because X = Y. This case is very unlikely to happen in real life.

Case 3 - the Pro is fed with the stream clocked at X, the Pro uses its own clock Y, the receiver gets the stream and synchronize to clock Y
Bit-perfect scenario, at least for 16 minutes content. I would guess that it's possible due to the under/overclocking behavior of the Pro. This case is the most common to happen in real life. It might probably happen that the results will depend on the source clock quality, so the next case to be tested later will use a source which tends to have a fluctuating clock.

 

[Labjr]

Yes, the issue mentioned here is related to squeezelite client behavior on the WiiM. It's not related to the toslink input.

But in the meantime I've tested 3 different scenarios in the digital domain when the WiiM is fed via its toslink input, to verify bit perfectness of the stream over toslink output. I've used 16 minutes file at 48 kHz as my source stream to compare it with the captured file.

Case 1 - the Pro is fed with the stream clocked at X, the Pro uses its own clock Y, the receiver gets the stream and synchronize to clock X
No chance for being bit-perfect because the number of received samples will differ from the source as long as X != Y. This case is very unlikely to happen in real life.

Case 2 - the Pro is fed with the stream clocked at X which is synced with the Pro clock, the Pro uses its own clock Y, the receiver gets the stream and synchronize to clock X
Bit-perfect scenario because X = Y. This case is very unlikely to happen in real life.

Case 3 - the Pro is fed with the stream clocked at X, the Pro uses its own clock Y, the receiver gets the stream and synchronize to clock Y
Bit-perfect scenario, at least for 16 minutes content. I would guess that it's possible due to the under/overclocking behavior of the Pro. This case is the most common to happen in real life. It might probably happen that the results will depend on the source clock quality, so the next case to be tested later will use a source which tends to have a fluctuating clock.

Interesting. I wonder if jitter is increased when this happens?

 

[Terence]

Am I right in thinking that if I use Itunes as my music manager and AirPlay as my player, then Wiim will give me AAC? But if I switch out Wiim for an old Airport Express, I get lossless? I've checked quite a bit and that's the only way to get lossless through Apple? I know this is Apple's fault. I'm moving away from them, after 30 years.

 

[AlPo]

Am I right in thinking that if I use Itunes as my music manager and AirPlay as my player, then Wiim will give me AAC? But if I switch out Wiim for an old Airport Express, I get lossless? I've checked quite a bit and that's the only way to get lossless through Apple? I know this is Apple's fault. I'm moving away from them, after 30 years.

What device do you use as a source? If it’s a tablet/phone, then the only way to output lossless/hi-res is a wired adapter. If you use a Mac, then you can select WiiM as your system-wide output, and WiiM will receive ALAC lossless stream from Apple Music (albeit not hi-res).

p.s. In my system ALAC lossless stream over AirPlay to WiiM still sound inferior to full hi-res wired output via SMSL PO Pro USB to SPDIF adapter into WiiM’s TOSLINK input

 

[Brantome]

Am I right in thinking that if I use Itunes as my music manager and AirPlay as my player, then Wiim will give me AAC? But if I switch out Wiim for an old Airport Express, I get lossless? I've checked quite a bit and that's the only way to get lossless through Apple? I know this is Apple's fault. I'm moving away from them, after 30 years.

Broadly speaking yes except for the specific Mac use case mentioned above and the use of airplay 1 on the airport express you mention, but again in both cases it’s only CD quality at best. Apple Music doesn’t play well over wifi with devices outside its own ecosystem.

 

[Musician]

Broadly speaking yes except for the specific Mac use case mentioned above and the use of airplay 1 on the airport express you mention, but again in both cases it’s only CD quality at best. Apple Music doesn’t play well over wifi with devices outside its own ecosystem.

Apple offer high res music but no way to cast the music lossless . Its very sad, and I have also walked away from Apple to TIDAL connect.
When Steve Jobs was in command of Apple , he was a true audiophile . Nowadays they risk loosing their soul.
I love the reability of their products but there are other players that care more for soundquality , like Quobus and TIDAL .

 

[Musician]

I got a message displayed today on the WiiM app saying my WiiM Pro had been updated with some changes to the SPDIF input (something about sample rate tracking? I forget). I re-checked for "bit-perfectness" (my DAC has an integrated bit-perfect test - ECDesigns' PowerDAC-SX) and the WiiM Pro is NO LONGER bit-perfect at 44, 48 and 88khz! It is only bit perfect at 96khz.

I have obviously turned off EQ and have it set to fixed volume output.

Test was performed with Squeezelite. It was bit-perfect before, no other changes have been made to my setup.

Firmware version is 4.8.539439

I have now listened carefully with the new firmware and with TIDAL connect there is no worsening of the sound.

 

[adias]

Has this issue been fixed in the latest firmware?

 

[Musician]

Has this issue been fixed in the latest firmware?

I wonder the same

 

[WiiM Support]

No. Maybe WiiM can give us some feedback on all this.

Hi Hopkins, Team

When streaming, the WiiM devices produce bit-perfect output with fixed volume and EQ turned off.

For optical inputs, the output may differ slightly due to the device managing clock skew between the upstream source and the WiiM.

I hope this clarifies your query.

 

[onlyoneme]

Hi Hopkins, Team

When streaming, the WiiM devices produce bit-perfect output with fixed volume and EQ turned off.

For optical inputs, the output may differ slightly due to the device managing clock skew between the upstream source and the WiiM.

I hope this clarifies your query.

What about missing samples / truncated stream when squeezelite client is used? I've reported it in #495021 ticket.