I'm getting a ton of resyncs (pcm5102a)

[daniel-sousa-me]

I have tried every possible combination of settings in snapserver and have looked everywhere, but I can't get rid of the constant resyncs.

I have tried this on multiple devices (both the servers and clients). Can you help me?

You can find here a good chunk of the log: log.snapclient.20231019205841.txt

[CarlosDerSeher]

First of all, which commit are you on? If it is not the newest, please try develop or master branch and see if that helps.

Your log shows the pcm chunk queue starves and therefore the resyncs are happening. This didn't happen previously? Did you change anything in your setup? Also 600ms buffer seems a little bit short maybe change sample rate to 44100 and increase buffer to around 750ms (see Readme.md for the exact number)

[daniel-sousa-me]

I'm on the latest one. I never got this to work properly before.

I have tried all convonations of buffer settings. I even tried a sample rate of 12000 to get a bigger range to play around.

[CarlosDerSeher]

These lines make me wonder

0;32mI (16675) PLAYER: 0, -1338us, q 20

For me it normally stays in +-200us range. How is it for you if it is working ok, if this is the case at all for you.

Which device is your server running on? I am guessing wifi only devices in your snapcast setup?

It's kind of late now so I can't think of where ghe problem is coming from. You could try enable some logs in netconn snapcast protocol decoding loop to see if lwip is passing in messages which fail to be processed in time.

For me a starving pcm chunk queue queue normally means disturbance in wifi signal, though I can't really tell anymore, as almost all my clients are connected by wire...

[daniel-sousa-me]

The server is an Intel N100 mini PC. I've also tried running the server on my laptop. The server is connected by cable, but the esp32 is naturally using WiFi.

I've put the esp32 near the router and it doesn't make a difference. Using RPis and my phone, both with WiFi, even from far away works without any problems.

I'll try to look at the netconn thing.

[CarlosDerSeher]

How frequently does it happen and when exactly is it possible to provoke behavior somehow?

Did it happen on earlier commits? Maybe I broke something in latest commits?

[CarlosDerSeher]

Also you could try replacing relevant parts using portMAX_delay with some finite value to see if something blocks chunks from being processed.

[daniel-sousa-me]

It turns out the problem was with my ISP's wifi router, even though it's supposedly very good. I took out a very old one I had and stopped having problems if I connect through it.

[CarlosDerSeher]

Maybe 40MHz / 20MHz channel width compatibility? You can set it somewhere in the code or maybe try different settings on your ISP's router

[CarlosDerSeher]

Or some QoS settings?

Glad it is resolved though

[daniel-sousa-me]

Thanks for going the extra mile!

I don't know if I want to spend more time with this, though. The wifi was also not working well on my laptop (different issues, though), but that is connecting with 5GHz, so those settings would be completely separated, I guess. I'm going to try to convince them to upgrade my router to the new wifi 6 version. I don't have any ax hardware, but maybe the newer version is more stable.

[daniel-sousa-me]

For people from the future: After contacting my ISP, we realised the router was choosing a busy channel. After changing the channel, the stream improved a lot.

[CarlosDerSeher]

For me a starving pcm chunk queue queue normally means disturbance in wifi signal, though I can't really tell anymore, as almost all my clients are connected by wire...

So this was the reason after all :)