bpa wrote: > Players do not need to have full track in memory before playing as for > example, this would mean some older players couldn't play 3-4hr > downloaded podcasts. Also waiting for whole file to be downloaded would > result in significant delay before playing started if player is in a > slow connection. > > When playing a file or a stream, the player reports to LMS how much data > has been received. > When the player undecoded buffer reaches a "low level"mark, LMS tell > player to start playing data whilst still downloading the rest of the > file. > > When two files are being played - the second file download is started > before first file has finished playing .
Thanks to all for the replies. Yes I understand that a track doesnt need to be completely in memory, the memory pages will follow a LIFO scheme where stale pages are reused. I know from looking at LMS running on my Linux system via "nmon" (into my transporter) that I typically see a burst of network I/O (and related disk I/O) towards the end of the current track when it loads preemptively the next track. I am looking to use squeezelite instead of the Transporter with LMS and squeezelite on the Linux PC (output via async USB). I guess once I try squeezelite, I can use "nmon" to track disk i/o and the loopback network stats (given LMS and squeezelite will talk via IPC) and see how it handles the loading of tracks. It was just interesting the various well known contributors on some non-slimdevices forums suggested such a wide disparity in squeezelite buffer size. Thanks again, Peter ------------------------------------------------------------------------ posnos's Profile: http://forums.slimdevices.com/member.php?userid=62955 View this thread: http://forums.slimdevices.com/showthread.php?t=111144 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
