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…
I learned a bit more about sendspin and now I know it has a buffer (a massive one, up to 30 seconds), it works a bit differently than snapcast in that regard, which doesn't fill a buffer like this. But as soon something unpredictable happens (like me skipping the song), it will clear the buffer but quickly rebuild it ahead of time.
This means, what happened to me, should not happen, in fact, I was able to continue to play the music up to 30s after disconnecting the wifi entirely because of the buffer. But obviously if disconnected, it is not syncing to the other devices anymore and stops playing music after the buffer runs out.
The issue I was facing was caused by SendSpinDroid
The Sendspin-protocol often gets a lot of breaking changes, so the only clients that work somewhat reliable are those provided by the Music-Assistant-Team. This is because it is still new and in alpha-stage (they claim beta but MA in general is a broken mess, not sure why they play pretend, they do that a lot sadly).
Unfortunately a lot of this stuff isn't communicated well from what the MA-Team presents it looks like sendspin is THE DEFAULT & A STABLE protocol for Music Assistant, when in fact, I run into issues all the time. I would've loved to know that before I decided to migrate to sendspin, it was a massive waste of time for me recently.
