philippe_44 wrote: > What's likley to happen is a timeout on Tidal side. A few technical > explanations if you are interested > > - SB players start requesting data and will consume as much as the > source (LMS/Tidal) can provide to fill up their internal audio buffer > (that can create a demand spike at the beginning) > - When the buffer is full, they will use TCP flow control to regulate > the HTTP download from LMS/Tidal > - During playback, player's buffer will empty and so players will use > TCP flow control to get more data from LMS/Tidal and so on. > > - When using my bridges, you have 2 levels of buffering : the one that > my bridge does (and by default it is unlimited) and the one that the > UPnP player does, which can be pretty large as well and is > unknown/uncontrollable > - In other words, the Bridge receives as much data as it can from LMS > (using the normal LMS HTTP/TCP flow control), put that in a local file > and then uses again HTTP/TCP to forward that buffered data to the UPnP > player > - I cannot control what the UPnP player requests, he controls me (and I > don't want to "guess" how much data the UPnP player has really > consumed) > - The Bridge unlimited local buffer mode can creates very large and long > spikes of data download to LMS and some services like iBBC are suffering > from that > - A while ago, I added the parameter <buffer_limit> that limits the size > of the Bridge's buffer and avoid too long spikes, but that has a > consequence on some player pause/resume capabilities (they want to seek > from the beginning of the data ...) > - I also added another parameter <pacing_size> which limits the amount > of data that the bridge can store "ahead" of the UPnP player. So, with a > limit of 1MB, when the UPnP player "flow controls" me, then I "flow > control" LMS as soon as the gap between what I have in my buffer and > what the player has accepted is more than 1MB. Still, if <buffer_limit> > is set to -1, I will buffer the entire track, but I will buffer it > "slowly" versus as fast as I can > > - Long explanation to say that the consequences of all these buffering > is that the Tidal side of the flow can see large pauses because even > with pacing of 1MB, if your UPnP player accept 64 MB of buffer, the > bridge will get from LMS/Tidal these 64MB and will forward it all. When > the UPnP player "flow control" me, I'll gather another 1MB and then > pause until the UPnP player requests more ... but that can be a long > pause and maybe, what happens there is that Tidal sees an idle time that > is too long and then closes the connection with LMS. That's just an > hypothesis, but seems to be consistent with what you experience. > > So, net net, if your player does not have problem with pause/resume, you > potentially can use <buffer_limit> instead (put it at 16MB) and with > that, the flow should be smoother, end to end.
Hi Philippe, Great explanation on what the bridge is actually doing. And it very well aligns with what I experienced. I too expect that it is the connection to Tidal that is timed out. Probably more to be demystified on the Tidal to squeeselite interface, in order to fully understand the problem. But I am happy to have it working, and I'll play a bit around with the <buffer_limit> parameter, to optimize a bit :-) Thanks, René ------------------------------------------------------------------------ bastrup's Profile: http://forums.slimdevices.com/member.php?userid=65544 View this thread: http://forums.slimdevices.com/showthread.php?t=103728
_______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
