Owen Smith wrote: > Turn QoS off and see what effect it has I would suggest. Because if it > tries to throttle your streaming audio data, it's going to make things > worse.
I think chunked http would confuse QoS as you don't get a continuous stream but burst of data and then quiet for 6 secs, then another burstt. I am coming round to the opinion that "chunkiness" is the root cause of the issue. With streamed audio - once a TCP connection has been made - audio data arrives without any further requests from LMS so even if LMS is very busy audio will arrive - only 1 GET is needed and the data just streams. Whereas with chunk/http . Each chunk is just 6 secs but requesting the next chunk will not happen a chunk is processed so there will be gaps between requests for chunks. This could explain why nonUK user with 96kbps has same problem as UK user with 320kbps - it is not bitrate that is the throttle but rate at which chunks can be requested is the throttle. With "Listen Again" it is possible to send 10 chunks requests at the start but with live the only way to order up a chunk is to go back in the past. If this chunkiness "pump priming startup" is the issue - then there is something in the socketwrapper implementation that is a little "off" with new processors & Win7/8/10 and perhaps it has appeared before just it wasn't identified (e.g. http://forums.slimdevices.com/showthread.php?106198-Windows-STDIN-and-Socketwrapper ) At the moment all I want is a workaround that's doesn't require a change to socketwrapper or LMS. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=104672 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
