Triode wrote: 
> Hi - I can definitely avoid calling setsockopt - it is there to make the
> buffer larger than default on windows and old linux version which
> default to smaller versions.  
> 
> As you have diagnosed spotifyd is currently using the tcp send buffer as
> the main buffer for the stream.  It tries to write to it whenever the
> callback from libspotify calls it with data and if it can't write to the
> socket then buffers it.  However it won't try to write again until
> libspotify calls it again.  This clearly means that it requires regular
> calls from libspotify and also a large enough buffer and in the tcp send
> buffer.  This was all working ok until something changed in linux...
> 
> Anyway let me look at whether another thread would be trivial or whether
> buffer tuning and not calling setsockopt is the easiest thing to do.

Hi, thanks for looking into this. I've tried some more variations.

1. Kept the 8MB buffer setting in spotifyd, but reverted to Ubuntu
defaults (131071), effectively limiting the actual (doubled) buffer size
to just over 256K. Still works nicely.

2. Reduced the size specified in setsockopt down to 65536. Better than
32768, but still flaky on very rare occasions.

3. Changed the setsockopt call from one that modifies the buffer size to
one that enables TCP_NODELAY. This was a complete and utter disaster.
The default buffer autotuning configuration in Ubuntu results in a
buffer that is around 56K (this is the doubled value) in size and
disabling Nagle doesn't improve anything.

So I think the best quick fix is to call setsockopt with a value of
524288. This should be good for most users, and for those that are
comfortable modifying TCP tunings, gives them some limited room for
adjustment without the risk of unnecessary buffer growth. But that's
just my opinion.

It really is bizarre that a change in Linux has caused this. I can't
think what it would be. With everything unmodified, there seemed to be
no issues with packet loss or anything like that and disabling the
firewall (ufw) didn't help. Only when I increased the buffer size did I
see the congestion window shrink occasionally. I wonder whether
something is inadvertantly delaying the sending of packets on the wire.


------------------------------------------------------------------------
Stevie P's Profile: http://forums.slimdevices.com/member.php?userid=9358
View this thread: http://forums.slimdevices.com/showthread.php?t=97851

_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Reply via email to