Hi,
recently I tried to setup a sendspin-client (sendspin-js & SendSpinDroid) on an Android-tablet and noticed the audio is dropping out for a split-second over and over again. After a while I noticed that it happens whenever I put something in between the tablet and the router (4m distance), probably increasing the latency by just a few milliseconds for a moment. But it seems like Sendspin increases the buffer or resyncing whenever this happens, because the playback continues as normal after the drop-out even if the object is still in between router and tablet. After removing the object, it seems like Sendspin is decreasing the buffer again, because if I put an object there again after like 2-4 seconds, audio drops out again.
So I was wondering, isn’t there a fixed on-device-buffer that would prevent that from happening!? And if so, how can I increase it to prevent those drop-outs? Or maybe there is another possible reason I didn’t think of yet… please let me know. Thanks
A bag of water is causing buffer and latency? I’m more concerned about WiFi signal. How is that?
Sendspin has Kalman setting I believe that I believe affects clock and maybe this has relation to buffer. I believe it’s added under sendspin_hub in yaml but I don’t have example to show. Below is info on kalman.
The wifi latency is expected. Objects within the line of sight cause more packages to get lost/currupted. Therefore they need to get send again, this whole process takes up time, increasing latency.
To be fair, it is a very old tablet but it has better specs than my Pi Zero that is running Sendspin perfectly fine.
Here are some more indicators I probably should mention:
Switching to opus codec (used flac before) mitigates it a bit. I guess it is able to receive more time per bit this way.
I get droputs from using the internet on the tablet. Probably cloging the slow WiFi connection while having no buffer to compensate.
Snapcast has no problems on any device (with flac codec), but it will set the buffer-size according to the sync-offset (which sendspin clearly doesn’t). Imho this is the only sensible way to do it, because even on other devices, using the network for anything data-intense often comes with audio-dropouts when using sendspin.
BTW. My setup looks like this:
Pi5(8GB) ->LAN(1Gb)-> FRITZ!Box 5690 Pro ->Wifi(n)-> Samsung TM-530(Android13)
Damn, that line killed my hopes for Sendspin solving my Snapcast issues with the clogged 2.4ghz surrounding I’m living in here. Was trying to stabilise my snapcast setup for a while now, but always ran into wifi being the issue. I actually only found this thread while searching for an answer to the question if sendspin does use a different/better buffering approach than snapcast, but well…
