Bugzilla – Bug 248
http://server:9000/stream.mp3 is several seconds behind 'real time'
Last modified: 2008-10-02 14:57:26 UTC
There seems to be a buffer within the slimserver http stream (in addition to that in WinAmp) that causes a long lag between pressing, for example, pause in the web interface and the music actually pausing. Should it be possible to reduce the size of this buffer as an option for those wanting minimal latency with a high bandwidth network which does not require a buffer?
Actually, SlimServer doesn't buffer data at all. The buffering is in the client. Sorry.
I was wrong. We do buffer up to 32k of data in the server before sending. We could clear out this buffer on a song change.
It seems very strange that you buffer (that much) in the server. It would only make sense if you thought that the file which the music is read from can become unavailable for some short periods of time. It seems very unlikely and would mean a problem with the disc the files are on. I don't see any reason to buffer on the server side, or am I missing something?
Not much we can do about this.
Why isn't there anything you can do about this? Could you please elaborate? Is the 32k for crossfading? At the very least could you point me to where the buffer is in the source, then I can change the thing myself?
There's no intentional buffering of data on the server side, it's just that SlimServer reads up to 32k to get started. That, plus the buffers in TCP on both the server side and client, coupled with the fact that the playback chain and the control chain are completely independent means that there's no control over latency. If you try to stop, pause or change songs, any unsent data is immediately deleted. If latency is a problem for you, your best bet is to use SoftSqueeze. That said, if you still really want to try to tweak numbers, the value of MAXCHUNKSIZE in server/slim/web/HTTP.pm is the closest thing you have to a tunable value. I doubt that it will have much effect.