Phil,
I don't have a magic bullet for this.
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.
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.
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.
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.
Certain issues are simply not addressable in software (802.11g support, as another example). For those issues we develop new hardware.
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. During those 30 days if you have some problem we will do everything we can to resolve it for you. We'd prefer to fix it, but you can send it back no matter what. This isn't a just some bullshit buying prod like on the late-night infomercials - we actually honor this policy. It protects you if the product isn't what you thought it was, it protects you if the price plummets, and it protects you if the product doesn't work. We get very few returns.
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.
Best wishes, Sean
On Mar 30, 2005, at 5:44 PM, Phil Karn wrote:
Jack Coates wrote:
heh... my machine is doing a lot more than yours and I never have skips. The key issue here is streaming FLAC, IMHO, exacerbated by the size of your library. My ears aren't good enough to tell the difference, so I play MP3 and a few OGGs. I wonder if you still see dropouts when transcoding? I bet that even with the increased CPU load of running the lame process, it would still come out performing better than you have now.
Well yes -- I totally agree that there's a *big* difference between streaming PCM (WAV, FLAC, Ogg and AAC) and MP3. I don't have any problem streaming MP3 either. The data rate over the LAN for MP3 is so much lower than raw PCM (320 kb/s max vs about 1411 kb/s) that the Slimserver has no trouble keeping the Squeezebox's fixed-size buffer from running completely dry in MP3 mode.
My playback skips occur only when I play a file format that has to be transcoded on the server to raw, high speed PCM. Then the fixed-size SB buffer drains much more quickly, and sometimes the Slimserver doesn't refill it before it empties completely. Then I hear a skip.
You're right, my skips *would* almost certainly go away if I transcoded everything to MP3 over the LAN. And yes, I have enough server CPU cycles to do that in real time. But that's a *kludge*, and I shouldn't have to resort to kludges. The Squeezebox is advertised as being able to stream raw PCM over a 100 Mb/s Ethernet LAN in real time, and that's just what I want it to do. All it would take is some careful attention paid to proper task/thread structuring and prioritization within the Slimserver package. I've bought three Squeezeboxes so far, and I paid a tidy sum of money for them. Why is it somehow unreasonable to expect them to perform as advertized?
--Phil _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
_______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
