WiiM Pro no longer bit perfect?

[hopkins]

This is primarily a user forum and WiiM only pop in occasionally. If you want feedback from them, best to raise a ticket as I suggested above

Doing that means they can inspect your device logs for evidence of the issue.

I just did

 

[Musician]

It still passes RME bit-perfect test.

They better continue to be bitcorrect - This is one of the reasons people buy them ( Im one of them ) and I also dont like any sample rate conversion.

The world is full of streamers that dont sound particulary good because the digital side it less good .

 

[Brantome]

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

In the interim, can you store the test files on your phone or tablet and play them from “My Music” in the WiiM Home app to see if it’s perhaps a Squeezelite/LMS issue?

 

[onlyoneme]

Short test for behavior when sample rate changes in the queue, LMS, test tone at 44.1 kHz:



51 samples missing at the beginning.



4664 samples missing at the end.

 

[hopkins]

Short test for behavior when sample rate changes in the queue, LMS, test tone at 44.1 kHz:

View attachment 4265

51 samples missing at the beginning.

View attachment 4266

4664 samples missing at the end.

So this confirms what I found?

Will check with files played from my phone as suggested above.

 

[Balthazar B]

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...

What happens when you play, say, a Qobuz playlist with tracks of different sample rates? Wondering if it's something related to the Squeezelite implementation or something more broad.

 

[onlyoneme]

More samples missing at the beginning in case of playback via WHA



and less at the end

 

[onlyoneme]

So this confirms what I found?

At least partially, but it would require a verification also in the analog domain IMO, as the recording software is out of sync with the DAC/DDC when sample rate changes and it can have some impact.

 

[hopkins]

I copied the files on my phone and now none of them pass the test, even when played individually. I also tried playing them from my phone through USB Audio Player Pro (through UPNP, with bit-perfect setting), and that fails as well. In my previous tests, these two configurations were bit-perfect. I checked again using LMS, just to make sure, and same results as before - bit-perfect when played individually, but not when played sequentially from a playlist.

 

[hopkins]

What happens when you play, say, a Qobuz playlist with tracks of different sample rates? Wondering if it's something related to the Squeezelite implementation or something more broad.

When I play a Qobuz playlist with songs of different sample rates the correct sample rates are displayed on the WiiM app, that's not a problem.

 

[Balthazar B]

When I play a Qobuz playlist with songs of different sample rates the correct sample rates are displayed on the WiiM app, that's not a problem.

What is your DAC telling you when the tracks change? Does it say they're still bit-perfect or not?

 

[hopkins]

What is your DAC telling you when the tracks change? Do things go sideways?

My DAC does not display sample rates. As mentioned previously, it has a build-in bit-perfect test that displays a character ("P") when the test is successful. So with a Qobuz playlist I can only see the change of sample rate on the WiiM app, and it displays it correctly.

 

[Balthazar B]

Ah, OK. Perhaps @onlyoneme has been inspired to run some more extensive testing with his RME.

 

[onlyoneme]

3.5 minute track sent to the DAC in a bit-perfect manner, so the issue is related only to missing samples when sample rate changes. But LMS had the same behavior as DLNA so far, so something went worse as it truncates around 0.1 sec at the end actually.

 

[ratty]

FWIW my RME is also reporting bit-perfect as normal, stepping through the various sample rates (44.1, 48, 96, 192). The files are being fed by DLNA from a BubbleUPnP server.
(It did pop the emphasis warning on one occasion, but that was a glitch at track/SR changeover.)

 

[hopkins]

3.5 minute track sent to the DAC in a bit-perfect manner, so the issue is related only to missing samples when sample rate changes. But LMS had the same behavior as DLNA so far, so something went worse as it truncates around 0.1 sec at the end actually.

That sounds like a very plausible explanation, and somewhat reassuring. But it would be good if they could fix this, and "guarantee" what they advertise.

 

[onlyoneme]

At least partially, but it would require a verification also in the analog domain IMO, as the recording software is out of sync with the DAC/DDC when sample rate changes and it can have some impact.

Confirmed also with UCX II and the Flex.

 

[onlyoneme]

Confirmed also with UCX II and the Flex.

And on the analog output, these samples at the end are missing.

 

[onlyoneme]

And, what's more interesting, no issue at all with missing samples when Roon is used instead of LMS.

 

[Balthazar B]

And, what's more interesting, no issue at all with missing samples when Roon is used instead of LMS.

Difference between transport protocols? Or caching?