Bugzilla – Bug 15650
Incorrect priority on SqueezeCentre components are contributing to buffer underruns
Last modified: 2011-01-14 13:49:31 UTC
Sorry if this is already in the DB - I've been meaning to report this for a while. I have a fairly slow server - which helps show up any processing power/buffer underrun issues. With the standard install on XP - SqueezeCentre runs as 'Above Normal' priority. This is good - unfortunately alac/flac and mov123 all run at normal priority. This is a problem just after a track change. The SB buffer isn't full - and so the streaming apps need processing cycles to fill he buffer. Unfortunately after a track change SqueezeCentre is refreshing the web GUI and controller. Since SqueezeCentre runs at a higher priority it can starve the streaming apps of CPU - so the GUI refreshes - but the playing of music can stop. Setting the priority of mov123 to high for a single track fixes this - but only for one track - since a new copy is run for each track. - Greg
We'll check this bug periodically for votes.
== Auto-comment from SVN commit #30113 to the repo by agrundman == == https://svn.slimdevices.com/?view=revision&revision=30113 == Bug 15650, set priority on child processes directly launched by the server. Unfortunately this is not a complete fix for this bug, as the actual transcoder processes still run at normal priority. Socketwrapper should be modified to adjust the priority of the processes it launches, and I'm not sure how to adjust the priority of the processes launched by the cmd.exe shell using pipes
Andy - I don't have an MS build environment to hand, but it looks like socketwrapper is already setting THREAD_PRIORITY_TIME_CRITICAL for the internal threads it creates. I think the suggested change would be to set the creation flags in the call to CreateProcess - line 571. I'm not sure what we should set this to though as if we make it realtime then it could freeze out other stuff. http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx
socketwrapper should set the priority of child processes to the same priority as itself. That would take care of half of this bug.
OK good, so we can definitely fix socketwrapper. I'm not sure how to fix transcoders that are launched from cmd.exe and don't go through S::P::Pipeline. Any ideas?
Moving P3 and lower bugs to next release target