sander;188506 Wrote: 
> While slim sounds appealing the idea that every signal is sent back to
> the server just seems unnecessary and wasteful.
> This is a $300 device with the processing power that used to be common
> in workstations. It's not an ATM where security is an issue, I can't
> think of a scenario where a volume/mute command from the unit should
> ever require authorization from the server.
> 
> It doesn't seem unreasonable to process certain commands
> locally/instantly and then report the status to the server.
> If the server doesn't know that the volume was reduced for a little bit
> is less important than the user waiting for a response from the server.
> I'm controlling the device not my server!
> 
> My expectation is that commands from the remote control which comes
> directly from me should preempt anything else going on, as much as
> possible. I don't think I'm alone here. I don't mind lag in somethings,
> but this just seems like failure by design.
> 
> For the record I have a Squeezebox with 70% 802.11g signal connecting
> to a 1gb RAM ReadyNas NV+ (which I know is a little slow) but I think
> Slim will ultimately be in for a rude awakening if they expect their
> competitors to be hampered by this same design flaw.
> 
> The Squeezebox can continue to play for a minute or two with the server
> completely off, so it is capable of some asynchronous behavior. All I'm
> asking is please take this into consideration with the various
> performance improvements you have lined up over the next year. I
> honestly can't recommend this device as long as it has this limitation
> because there's no telling when this can crop up in a wifi network.

I don't think you're aware of how limited the squeezebox's CPU is..
just because the spec sheet says "250mhz" doesn't mean you can compare
it to a desktop CPU.

1: the squeezebox(2|3) has 8MB of ram.  From the spec sheet of the
IP3000 CPU, it can only address 4MB of that, so I'm not sure how the
ram is laid out.  Most of this ram as you noticed goes into network
buffering.. leaving less than 1MB of ram for the OS on the squeezebox.

2: the entire OS code for the squeezebox has to fit in a tiny ammount
of flash space (2MB I think).  This includes all the drivers for the
wifi and ethernet cards.  Audio codecs (mp3, ogg, flac, etc) and some
of the screensaver code is also local.

It may be time to update and improve the squeezebox network protocol a
bit to handle spotty server/networking.. but right now, this could all
be fixed on the server side.  The code that handles requests from the
squeezebox needs to be broken out into it's own thread.

One question: are you running 6.5.1.2 on the ReadyNAS?

If the ReadyNAS slimserver supports webserver forking, you might want
to enable that to prevent web page loads from interrupting the
squeezebox requests.


-- 
SuperQ
------------------------------------------------------------------------
SuperQ's Profile: http://forums.slimdevices.com/member.php?userid=2139
View this thread: http://forums.slimdevices.com/showthread.php?t=33695

_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to