hickinbottoms wrote: > 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.
I'm (fortunately) not suffering dropouts --- am I right in thinking that the SB2/3 have larger internal buffers? The main issue is that slimserver does seem to make the computer generally less responsive, regardless of whether it's actually streaming at the time. It would hence be nice to be able to have the time critical bits running with a high priority, making the system nice and responsive, and to have the CPU intensive, less time critical bits running with a lower priority so as not to interfere with normal computer usage. I presume that as the effort is going into splitting off the scanning, that that's where most of the CPU is going, and that once that's done, the occasional CPU hogging will cease. Nevertheless, it does seem to make sense to split off the streaming so that one doesn't have to worry too much about slower tasks elsewhere. I don't really know what involved in the following, but I'd be interested to hear some opinions on whether there's any merit in splitting things up somewhat more, having threads for: Streaming; The web interface; Scanning; Each connected client. This would mean that any slow operations, whilst potentially taking a while to return, would not grossly affect other users. Even with a relatively small music collection, some operations are fairly slow to respond, with delays of up to a few seconds. This isn't a problem with one squeezebox, but with several, I can imagine it could get really quite annoying to have the display freeze whenever another user was doing something slow. Chris Key _______________________________________________ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
