sander wrote: > My understanding the way it is now: > > remote volume down pressed->Squeezebox: Volume down > Squeezebox->SlimServer: Is this OK? > SlimServer->Squeezebox: It's OK. > Squeezebox: Volume down
I don't think that's quite right. My understanding is: remote volume down pressed->Squeezebox: key press detected Squeezebox->Slimserver: I've received a key press on the remote with hex code x3f (or whatever) Slimserver maps keypress to action: volume down Slimserver->Squeezebox: turn volume down Squeezebox: Volume down i.e. the Squeezebox has no concept of what remote keypresses map to what functions - it's all done on the server. > What I would like to see: > > remote volume down pressed->Squeezebox: Volume down > Squeezebox: Volume down > Squeezebox->Slimserver: Volume turned down > > My assumption was since this is something the Squeezebox already does, > and the cpu is capable of, I was just wondering if the architecture was > flexible enough to allow this. SuperQ and ceejay both said this is not > the case, everything is done on the server by design and no exceptions > are allowed. > > As a neophyte processing some commands locally, and doing somethings > like scrolling text, completely independent of the server makes sense > to me, but I'll defer to the experts on other consequences of those > changes. As Sean has already posted, it's not the client/server architecture that is the problem. What happens with the current server architecture is that all functions are running in a single process (remote handling, sound streaming, display driver, etc). If one of those functions is working hard it can starve the other functions of CPU time, with the resulting loss of responsiveness. One possible solution would be to re-architect the server software to use multiple processes - this is already partly underway with the scanning process running as a separate process. R. _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
