Sean Adams wrote:
When I started designing the Squeezebox1 hardware in 2002, I fully realized that an enormous buffer would be desirable. However, the architecture (which was chosen based on a long list of goals including ethernet/wireless capability, ability to drive a graphic VFD, OS performance, etc) unfortunately did not have an SDRAM interface, only SRAM, which meant that a very large (several MB) buffer would not be possible. Dean and I did a great deal of testing and never saw any problems on wired ethernet under any OS. On wireless networks there were some issues at first, which were quickly eliminated, most of them anyway, with some careful tuning of the TCP stack.
I understand your design constraints. Memory is nice, but it can also be expensive and you don't want your box costing more than it really has to. That's quite reasonable.
What we found was that in the real world there were still a few problems. I spent many weeks studying packet dumps and optimizing TCP (http://www.seanadams.com/ip2k), testing on Windows, Mac, and Linux, getting feedback from customers, and making improvements.
Yup. Many stacks do have glitches, although I think the later Linux stacks behave very well, especially when the entire path is just a few high speed Ethernet hubs. A bigger issue, I think, are the OS and disk scheduling algorithms.
It is no secret that a bigger buffer would be nice - in fact I think this request has been in our public bug database since its inception. Unfortunately the only way we can make the buffer larger is to make new hardware with a larger buffer, which is exactly what we've done. Optimizing streaming performance is still an active goal.
But I don't think that buffer *has* to be huge. If it does, then that's a symptom of brokenness someplace else, specifically in the server and the way it is treated by the operating system on which it runs.
PCM streaming on Squeezebox1, even with its 256K buffer capacity, works as advertised in nearly all environments, unlike my car which can only reach its advertised top speed on less than 0.01% of the road surface in the USA. I realize this is a retarded analogy and not a kind response but consider this: we are more open than any hardware company (that I know of) in terms of admitting where there's room for improvement (bugs.slimdevices.com). We view this information not as a liability, but as priceless guidance in how to make our products better.
Um, I assume you didn't mean that as a serious analogy! A better analogy would be to the per-mile probability of my car suddenly and without warning, seizing up and stopping dead in the middle of the freeway. Then, after a few seconds, the tires screech and it suddenly lurches back up to 65 mph just as unexpectedly. :-)
Certain issues are simply not addressable in software (802.11g support, as another example). For those issues we develop new hardware.
Understood. Since you advertised those hardware limitations, I can't complain. Your transcoding scheme to optionally limit the network bit rate to something it can support was a very nice touch.
Finally, as protection we provide a 30-day no questions asked return period. If the product doesn't work the way you want it to, or even if you just have a change of heart for some reason, we'll take it back.
Well, that's problematical when the problem is in software, not hardware. Again, I have no complaints about the Squeezebox hardware, either version 1 or version 2. If the hardware were broken, mis designed or otherwise unusable, then it would be easy to decide to return it in the 30 day period.
But the hardware is all fine; all of the problems I've encountered have been in server software, and that makes returning the unit a much harder call. You never know whether a given problem that you consider really serious will be fixed tomorrow or next week or next month or next year. Believing strongly as I do in the power of open source, I have decided to keep all three Squeezeboxes and wait for the software to improve. And that can be frustrating. Yes, I could roll up my sleeves and jump in and hack the code myself, but the Slimserver package is already a very large chunk of code that presents a dauntingly steep learning curve to anyone who wants to modify it. Confronted by it, I'd be strongly tempted to start over from scratch, or by adapting existing, mature mechanisms that I already know to work well (e.g., adapting the standard printer spooling system to manage queues and play lists for a Squeezebox.)
I don't know what else to say - we vastly improved PCM streaming performance by adding a huge buffer, adding 802.11g wireles support, and adding lossless compression. At the same time we added a whole slew of features in SlimServer 6 which improve SLIMP3, a product which we began selling out of my garage in 2001, and of which we have not sold a single unit since 2003. I realize that these are not huge time scales in the grand scheme of things but still, I'm lucky to get free bug fixes or free feature additions for anything after six months or so. We're doing everything we can Phil.
I know you are, and I still think you have an excellent product with enormous potential. That's why I don't want to just give up on it and ask for my money back. It's just that sometimes I think the priorities of those working on the SlimServer code are a little odd. I cannot be the only one who thinks various bells and whistles like a dozen and a half web skins and crawling news feeds and audio visualizers simply aren't as important as ensuring the basic functionality of the system (playing music) and making it as reliable, available and portable as possible.
Phil _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
