cjk32 Wrote: > It would be nice to be able to run the thread serving audio data with a > high priority, the web interface at normal, and the scanner at low > priority. > It'd certainly be of use to people like me who don't run slimserver on > a dedicated server.
I'm not even sure that's necessary. I see this as well (to the extent I avoid the web interface altogether while playing, which is a shame), and I suspect the stalls are simply because the main application thread (which also currently streams audio to the players) is taking too long between each fill operation. I suspect that's as much IO wait time as pure CPU hogging - eg if the database is thrashing the disk doing a search then the CPU probably won't be maxed out, but because of the architecture that spare CPU time won't be used to fill the players. Filling the players is actually a very low-CPU-use activity (even with transcoding it takes surprising little CPU to stream over the network). I wouldn't be surprised if simply breaking out the player streaming to another thread/process would solve this problem without having to mess around with priorities at all. I've personally looked around to try to increase the socket buffer size within the server to try to compensate as I'm convinced that the stuttering I get is because of the server not filling the server-side socket quick enough, rather than because the network bandwidth has become exhausted. Given that it takes almost no CPU to then get that data over the network I was hoping this would effectively extend the SB1's limited buffer. I didn't have any joy with that approach, though. I'd therefore also prefer the streaming to be split off rather than the scanning - after all most of the performance problems reported are because audio stutters during scanning, not that the web interface is sluggish. However, I know the Slim Devices developers have looked into it quite a bit more than I have so they may have much better evidence than my simple gut feel as to why the current development is the right one. I suspect such an architectural change would become easier once the main pain of moving the scanning out has been taken, because that will already have proved a multi-process architecture that shares access to the database successfully. Once that's done it doesn't sound too complex to have a small separate process/thread that reads the top of the playlist from the database and streams that out (with any transcoding necessary). Does anyone know of a bug for this in Bugzilla? If not it might be worth creating one so that it could be voted for. -- hickinbottoms Stuart -"Never put off until tomorrow what you can put off until the day after - with Lazy Searching!"- ------------------------------------------------------------------------ hickinbottoms's Profile: http://forums.slimdevices.com/member.php?userid=255 View this thread: http://forums.slimdevices.com/showthread.php?t=23641 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
