philippe_44 wrote: > Still, if you think about the original squeezelite, it has an internal > buffer of 2-8MB, so this is already a lot. Of course I'm adding more > than that through the local filer buffer as the internal buffer gets > flushed immediately, but I think expanding the other timeout will solve > definitively the problem. That timeout could even not be needed, really. > This is an artefact from my very initial solution
THis is my theory. AFAICT the design of LMS expects each player to be served with data until it is "Full" (or in the case of live a threshold) whereupon it will go quiet, play the audio at normaltime and then data need only be sent to it a in small lumps as audio data is consumed. The round roibin scheduler in LMS shares its time amongst web pages and players. You said Castbridge has effectively an infinite buffer in which case it will take a whole audio file before saying full so for a burst it will take a disproportinate amount of time compared to the players but with a finite file it will end. I've made DASH live stream to be infinite and the player's buffer is infinite. This needs ot be checked out and also determine why/how HLS does not fall into this trap and at the same time avoid the rebuffering/DNS problem of HLS. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=104614 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
