PDA

View Full Version : Why is the Squeezebox so dependant on the server?



sander
2007-03-17, 14:56
I've had my Squeezebox V3 for about a year now and got a ReadyNAS NV+ a couple of months ago to complete the set. Now I'm aware of the various performance issues between the two, but I've made my choice, and I can live with it most of the time, but one thing infuriates me to no end:

Why does the Squeezebox hang at all when issuing commands that are entirely local to the unit? Why does it need to check with the server to lower the volume or stop? This makes no sense, and bugs the hell out of me the 5% or so time that it's not instantaneous.

According to your literature the chip inside is multi-threaded, but I see next to no evidence of this because the scrolling is almost always choppy and whenever the server is busy everything stops except for the buffered playback.

Will this ever be better in a future firmware release or is this a known limitation to the server/device?

ceejay
2007-03-17, 15:30
This is central to the design philosophy of the device - it is "slim", absolutely all the work is done on the server. Every single button press on the remote (well, nearly every one...) goes back ot the server, which decides what to do with it and then sends whatever it needs to back to the device.

Thats just the way it is. Anything else would be a completely different device.

The fix is to get a meatier server - all the NAS devices seem to be pretty limited. You might be able to improve performance with a memory upgrade?

Ceejay

egd
2007-03-17, 16:14
Now I'm aware of the various performance issues between the two, but I've made my choice, and I can live with it most of the time...Will this ever be better in a future firmware release or is this a known limitation to the server/device?

The NV is underpowered, so you're pretty much best off limiting the NV to one task at a time ie if playing music, forget about doing anything else on it.

sander
2007-03-17, 16:23
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.

SuperQ
2007-03-17, 18:57
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.

TimothyB
2007-03-17, 20:09
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.
I thought that by using a custom .map on the server, one could pretty much completely change what the remote buttons do.

-- Timothy
(Also, I believe that someone has written a plugin that when his wife turns the volume down, the server gradually cranks it back up again.)

SuperQ
2007-03-17, 21:02
I thought that by using a custom .map on the server, one could pretty much completely change what the remote buttons do.

-- Timothy
(Also, I believe that someone has written a plugin that when his wife turns the volume down, the server gradually cranks it back up again.)

I think what meant was not "Authorization" as in security, but as in Confirmation. There is no authentication or security in the slim protocol, but all remote presses are passed back to the server for handling, which is why you can do random things with the remote map. Therefor the server must confirm and act on any command sent via the remote.

This is my understanding of how things work:
remote key volume up -> squeezebox -> server -> map key to volume change -> send volume change update to the squeezebox.

This is a very simple, lightweight, and synchronous design. The only disadvantage is that if there is latency introduced at any stage in the pipeline, say the slimserver is busy and does not respond to the keypress, UI is adversely affected.

The CPU on the squeezebox is great, is has a very tightly controlled code base. The CPU in the slimserver is whatever the host machine has, and CPU time is not tightly controled, and the slimserver can be starved for resources.

What this person wants is the volume control logic to be pushed into the squeezebox, and the slimserver is asynchronously updated of volume change events on the squeezebox. This would require a bunch more code on the sqeezebox to handle all the various configuration options that people have built into the slimserver.. fixed volume modes, analog disabling, etc. The protocol would also have to be updated to support async updates and conflict resolution.

A user changes the volume on the squeezebox with the remote at the same time someone clicks "volume output is fixed" on the slimserver. You would need a millisecond timestamp sync between the server and the squeezebox(s) to determine which configuration would win. I'm not saying this is impossible, it's just a lot more work than doing sync updates to the device state.

JJZolx
2007-03-17, 22:42
This is a very simple, lightweight, and synchronous design. The only disadvantage is that if there is latency introduced at any stage in the pipeline, say the slimserver is busy and does not respond to the keypress, UI is adversely affected.

Simple is the keyword here. The "only" disadvantage to this approach is that it's one that is not going to fly in the consumer world. I don't care how you rationalize it: It's a dead end. You can't rely on the computing power of an arbitrary server, what that server might be doing, what it might be running, how f****ed up it might be in terms of ant-viruses and spyware and every other thing under the sun. No company in its right mind would put itself in the position to deal with all the support headaches that scenario entails. SlimServer and Squeezebox has done well so far due to the geek appeal and the reliance on the knowledge of its user base. That's about to end.

kdf
2007-03-17, 23:19
On 17-Mar-07, at 10:42 PM, JJZolx wrote:
> . That's about to end.
>
got any stock tips?
-kdf

erland
2007-03-17, 23:45
The "only" disadvantage to this approach is that it's one that is not going to fly in the consumer world. I don't care how you rationalize it: It's a dead end. You can't rely on the computing power of an arbitrary server, what that server might be doing, what it might be running, how f****ed up it might be in terms of ant-viruses and spyware and every other thing under the sun. No company in its right mind would put itself in the position to deal with all the support headaches that scenario entails. SlimServer and Squeezebox has done well so far due to the geek appeal and the reliance on the knowledge of its user base. That's about to end.I really like the current approach where most logic is in SlimServer, the main reason is that it make the SqueezeBox behaviour very customizable. With all the logic in the SqueezeBox we would probably have a solution with closed source software and none or very few plugins.

However, I also think you have a point. We have seen plenty of support issues in the forum since the 6.5 release, but as you indicate I also suspect that the number of issues are going to raise a lot when SqueezeBox enters the massmarket.

One solution would be to also sell a SlimServer hardware solution with pre-installed working SlimServer. This would get rid of most of the support issues, but the problem is that the total price of SqueezeBox + SlimServer box would be at least the double of todays price. At that price other companies solutions will start to look very interesting for most people compared to SqueezeBox. Especially since the massmarket really doesn't care much about sound quality, it just has to be "good enough" and this is something that most streaming devices today fulfills.

Another solution would be to change the whole concept of the hardware to go from a slim device to a fat device. The problem here is that this would probably mean that most of the SlimServer software needs to be rewritten, which would result in huge development costs. Another issue with this is that it would mean that SqueezeBox wouldn't have much key features that distinguish it from other similar devices. The only key feature I see that really would remain is the display.

So I think the easy way out is to improve the installation program so it detects possible problems. It might also be good to have some additional verification software that can be executed to verify the environment SlimServer is running in. These efforts should be focused on the Windows environment, because thats the environment the massmarket is going to use. Support issues for people running SlimServer on NAS boxes, Linux or MAC will probably be possible to handle in the same way as today.

amcluesent
2007-03-17, 23:59
>You can't rely on the computing power of an arbitrary server<

Has anyone told Google?

totoro
2007-03-18, 10:00
>You can't rely on the computing power of an arbitrary server<

Has anyone told Google?

Those aren't _arbitrary_ servers. Google _owns_ them, and has gone to a lot of trouble over the years figuring out what specs work for them.

sander
2007-03-18, 11:02
SuperQ: Thanks for the clarification, I'm not an embedded programmer, or even a regular programmer, but it seemed simple enough to me. I'm running 6.5.1 and in general (90+% of the time) the response from the Squeezebox is almost instantaneous, even artist searches in lazysearch, but on the rare occasion that the volume doesn't work, I get very frustrated as I don't want to have to use the component remote as well.

Also I think at the level of investment ($200+ outside of special sales :) ) the satisfaction level of the Squeezebox is lacking when you're occasionally faced with this dilemma. People may tell me otherwise, but I think regardless of the server power, in a wifi network you're always going to get latency.

While I can understand the idea of feeding everything through the server makes sense, in real world usage the response from the remote trumps any control from the server in terms of volume. I sometimes use Moose as an ersatz remote, but I would gladly sacrifice any volume control from the server. If I want it silent from a server interface I can always pause or stop it.

My feeling is everyone understands and experiences server lag on a daily basis, but people get very frustrated when the completely lose control of the UI.

My hope was that this was something that was being worked on, but it sounds like it's part of the design. The goal of 7.0 so things should only get better going forward and I can alway opt for another machine to host my SlimServer, but I think making as much of the UI run local on the Squeezebox will result in the most noticeable performance improvements for many people.

I'm happy with the Slimserver/ReadyNas combo, but I'm nerdy enough to forgive their shortcomings, and appreciate the great forums like this. People ask me for recommendations all the time on this type of stuff, I'd like to be able to recommend these devices, or similar, without reservation. But it sounds like running Slim on anything besides a full PC at this point would be too frustrating for the less technical. And with most configurations costing more than $1000 in extra hardware and effort just to run MP3 through their stereo people will just pass.

I work in IT so I have to apologize for poor design decisions at multiple levels everyday, I don't need that at home as well. :)

Pale Blue Ego
2007-03-18, 11:33
Your server and network are not optimized for speed, yet you get satisfying response 90+% of the time. You're complaining about speed but you have chosen slower hardware.

Using even a cheap, throwaway PC as the server would likely eliminate all the problems. A wired ethernet connection can improve response, too.

mherger
2007-03-18, 13:20
> I sometimes use
> Moose as an ersatz remote, but I would gladly sacrifice any volume
> control from the server.

That's a very interesting remark: if you can use Moose's volume control,
but not the remote, than you've very probably got a communication problem
between your SB and the server, not a performance issue on the server.
Moose uses the same server to handle the volume as does using the IR
remote control. If this is instant, compared to the remote, then you
should check your network connection. Try using cabling instead of
wireless (if you do use it - haven't read all the details).

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

Paul_B
2007-03-18, 13:35
This is an interesting discussion. For Slim to penetrate the mass market then they are either going to have to create a server solution to run Slimserver or the SB4 is going to be a fatter client to offload the server.

From my own experience the SB3 is fantastic and changed the way I listen to music. I am so glad the SB3 supports lossless formats and is aimed at good audio reproduction. Playing MP3 at 128K through a decent audio hi-fi setup is nonsense.

My system is wired and I have moved away from a NAS solution to dedicated server. Howver the server is a Mini-ITX solution which I put together for less than 400 and it consumes just just 25W. By NAS is now purely a NAS device.

I believe streaming shows up the inadequacies of WiFi and this is not the fault of Slim. If your can't run dedicated Cat5 then why not look at using your power circuit and use the numerous Powerline devices on the market?

sander
2007-03-18, 14:45
Well, I'm bringing up this one issue because I see it as something Slim could possibly address in future releases, or should at least consider IMHO.

The hardware I'm using has been advertised as compatible, and acceptable according to both companies in a joint press release and on both of their home pages as I recall. I paid an extra $50 for an included wireless and I don't have a wired home. I'm not starting a poll or submitting a bug report or a web protest page, overall I'm a happy camper. I'm just saying based on my experience this is sometimes a problem, and here's a possible solution.

Moore's law is still in effect and to continue to load everything on the server is a mistake IMHO. The real hole in the thin client setup is that chips keep getting faster, so basically all you end up doing is crippling increasingly powerful chips with a mainframe/terminal based approach.

Sitting 2 feet from my Squeezebox is a Galaxymedia TVisto multi-media hard drive enclosure. It's fugly, there's no community forum that I know of, it doesn't have a network connection, but for less than the price of a Squeezebox you can get one with a 400GB hard drive and it has most of the same audio playback functionality with video as well, with no server at all.

I don't consider it a replacement for the Squeezebox, but for the average user it's much more idiot-proof and if it had an led display it would be a viable competitor.

I have a minor vested interest in Slim at this point and I'd like to see an open technology succeed as opposed to some proprietary soup from Redmond or Cupertino, but they really need to attack the performance problem from every angle. The other guys are going to throw hardware at the problem at every level, Slim's going to get buried by one of big boys if they're not careful.

I don't want the Squeezebox to become some cumbersome beast, but it seems to me there's some low hanging fruit which could make the Squeezebox's UI more responsive, reduce network traffic, and server load. If that's not the case then so be it, it's just an idea, and I wanted to put it out here.

Laz
2007-03-18, 20:58
Guys,

I agree with the OP about remote latency, connectivity and buffering. These are all a pain in the backside for me.

However, they are also own goals, because I'm using an underpowered server, one of my wireless routers is surrounded by electronics, the other is surrounded by more electronics and sits in a Faraday cage style metal stereo rack, and I keep them at opposite ends of a house with significant rebar. I'm perpetually amazed that my network works at all. Even so, the only time latency becomes really ignificant is when I'm working with both iTunes and slim at the same time.

As I see it, Logitech/Slim can deal with this issue by simply upping the minimum required server spec and bandwidth requirements for the broader release.

Most people will not be terrible stressed to see a requirement for a 2GHz+, 2GB+ @ 54MBs or better. If you want to get by on less powerful hardware, you can, but don't be too surprised by the performance hit you suffer.

pfarrell
2007-03-18, 21:19
Laz wrote:
> As I see it, Logitech/Slim can deal with this issue by simply upping
> the minimum required server spec and bandwidth requirements for the
> broader release.

Yeah, but they probably don't want to say the real solution: use wired
networking ;-) Or at least, use only one hop of wireless.

> Most people will not be terrible stressed to see a requirement for a
> 2GHz+, 2GB+ @ 54MBs or better. If you want to get by on less powerful
> hardware, you can, but don't be too surprised by the performance hit
> you suffer.

That is way overkill. I ran for years on a P3-500 with 386MB, and
currently run on an AMD 2400+ (about 1.5 gHz) with a gig of ram, Wifi G.

Since ram is nearly free, I don't see any reason to not put in lots, but
as a minimum, I think you're over specifying it, and will scare people
away who would be happy campers.

Running Slimserver on a 600 mHz NAS really should be warned against.
IMHO, of course.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

peter
2007-03-18, 23:24
Pat Farrell wrote:
> Laz wrote:
>
>> As I see it, Logitech/Slim can deal with this issue by simply upping
>> the minimum required server spec and bandwidth requirements for the
>> broader release.
>>
>
> Yeah, but they probably don't want to say the real solution: use wired
> networking ;-) Or at least, use only one hop of wireless.
>

And then there's people using 4 SB3's on wireless without latency problems.
Of course the server is wired, who'd ever put a server on wirelesss?

>> Most people will not be terrible stressed to see a requirement for a
>> 2GHz+, 2GB+ @ 54MBs or better. If you want to get by on less powerful
>> hardware, you can, but don't be too surprised by the performance hit
>> you suffer.
>>
>
> That is way overkill. I ran for years on a P3-500 with 386MB, and
> currently run on an AMD 2400+ (about 1.5 gHz) with a gig of ram, Wifi G.
>
> Since ram is nearly free, I don't see any reason to not put in lots, but
> as a minimum, I think you're over specifying it, and will scare people
> away who would be happy campers.
>
> Running Slimserver on a 600 mHz NAS really should be warned against.
> IMHO, of course.
>

I've had a server since 1994 and it's becoming more useful everyday.
None of that NAS stuff for me.

Regards,
Peter

Laz
2007-03-19, 01:25
That is way overkill. I ran for years on a P3-500 with 386MB, and
currently run on an AMD 2400+ (about 1.5 gHz) with a gig of ram, Wifi G.

Since ram is nearly free, I don't see any reason to not put in lots, but
as a minimum, I think you're over specifying it, and will scare people
away who would be happy campers.


I was indulging in a bit of hyperbole.

My point was that the minimum requirements for slimserver are quite low relative to the performance of a new, cheap PC - and cost of such a PC is about the same as one squeezebox! Given this, why not just raise the bar for recommended minimum server specs and reduce the scope for broader market complaints about responsiveness?

Cheers,

Laz

Paul_B
2007-03-19, 02:38
The problem with NAS devices is they just aren't. Conceptually the NAS boxes such as QNAP were originally specced for serving files to a network. But more and more has been added to them in the form of bit torrent, web server, Slimserver, etc. They are no longer true NAS but a central server. As a server they are under powered and this is especailly true since the release of Slimserver 6.5 and using the web interface. Add to this the inadequacies of Wi-Fi and it is not a pleasant experience.

I discovered this myself and is the reason I went down the Mini-ITX route and built a central server. I find it much more flexible to my needs because I can just download and install the latest version of Slimserver or Plugin.

This machine is not that powerful. It is 1.5GHz with 1GB of RAM but it also acts as my print server, WINS, DNS, DHCP, Web-server, Home-automation server, file server, and Slimserver. It never complains and sits in the garage headless and consumes just 25W. The QNAP now is back as a true NAS device and just gives file-access on the network

Marc Sherman
2007-03-19, 05:23
sander wrote:
>
> I work in IT so I have to apologize for poor design decisions at
> multiple levels everyday, I don't need that at home as well. :)

Jonathan?

- Marc

Mark Lanctot
2007-03-19, 08:03
I work in IT so I have to apologize for poor design decisions at multiple levels everyday, I don't need that at home as well. :)

I'm not so sure it's a poor design choice. Since most of its power is housed in the server, the Squeezebox is the most customizeable, flexible, changeable tech device of any sort available today IMHO.

I have what would be considered an older PC but it does all my everyday tasks and runs SlimServer without complaint or stress. And on only 512 MB of RAM. I'm really quite surprised that the majority of people run 1 GB since I've never had any issues with excessive page file usage - I have to open 10+ uncompressed raw images in GIMP before I get into paging.

jonheal
2007-03-19, 09:02
Since ram is nearly free, I don't see any reason to not put in lots...

Please send me your extra free RAM. :-)

pablolie
2007-03-19, 11:05
The sceptics on the architecture better take a look around... I think it makes *total* and utter sense to use *one* PC in the house as a server for all sorts of things - that's where the most cost effective and largest concentration of CPU power and storage is always going to reside - so I want it to do more than just act as a text editor and Internet browser. The more and harder it works, the more mileage I am getting out of my investment in a household server.

The SB3 is a brilliant concept, in my opinion, providing an *optimal* bridge between that computer in its function as a media repository, and my specialized audio equipment, which for the time doing will do a better job in its function, or perhaps has just trained my ears to have me very convinced that it does. :-)

I actually would not like for a heavier computer to be anywhere near my audio environment, but for those who don't care... build up a small and cheap PC with good power standby capabilities, close the the SB and be done with it. The SS requirements are very modest, really.

I for one think we better get used to the concept of an "always on" computer in the house. Of course the power management capabilities should be robust, but that is quite common place I would hope - mine actually will spin stuff down and consume little power when nothing is happening.

But other than the power concerns -and I'd need to be convinced that multiple CPUs doing specialized tasks in different parts of the house can be more power effective- I see only advantages to the concept - one user interface and one remote (one sweet day! The Pronto is not the relief I expected!) for all functions!

seanadams
2007-03-19, 12:58
UI latency is generally caused by slowdowns in SlimServer which have nothing to do with the hardware interface being on the other end of a network connection. Trying to fit the capabilities of SlimServer into an embedded device would be impossible if it were any less capable than a complete PC.

One could reasonably argue for a "Slimmer" server, or for software architecture improvements to reduce response time, but blaming the client/server architecture doesn't make much sense. A simple ping will tell you precisely how much of your interface lag time is caused by the network.

Mark Lanctot
2007-03-19, 13:08
The sceptics on the architecture better take a look around... I think it makes *total* and utter sense to use *one* PC in the house as a server for all sorts of things - that's where the most cost effective and largest concentration of CPU power and storage is always going to reside - so I want it to do more than just act as a text editor and Internet browser. The more and harder it works, the more mileage I am getting out of my investment in a household server.

The SB3 is a brilliant concept, in my opinion, providing an *optimal* bridge between that computer in its function as a media repository, and my specialized audio equipment, which for the time doing will do a better job in its function, or perhaps has just trained my ears to have me very convinced that it does. :-)

I actually would not like for a heavier computer to be anywhere near my audio environment, but for those who don't care... build up a small and cheap PC with good power standby capabilities, close the the SB and be done with it. The SS requirements are very modest, really.

I for one think we better get used to the concept of an "always on" computer in the house. Of course the power management capabilities should be robust, but that is quite common place I would hope - mine actually will spin stuff down and consume little power when nothing is happening.

But other than the power concerns -and I'd need to be convinced that multiple CPUs doing specialized tasks in different parts of the house can be more power effective- I see only advantages to the concept - one user interface and one remote (one sweet day! The Pronto is not the relief I expected!) for all functions!

Excellent post.

Adding player resources, even today, is still expensive while there are VAST unused resources available in any typical PC.

It's not like the SB/Transporter CPU is sitting there doing nothing. Quite the contrary, Slim has put it to good use and is, in fact, stretching it to the limit: the Transporter even with the binned 325 MHz CPU, between 24/96 playback, ReplayGain and the spectrum analyzer, will run out of CPU cycles: http://bugs.slimdevices.com/show_bug.cgi?id=4463

In order to do everything the SB does today plus act as its own SlimServer, the CPU would need to be a lot more powerful. This would (ironically) be bad for power consumption. The SB already gets knocked for consuming 5W on idle - this would double or triple.

But my PC is already always on, and it's still less than 1% CPU while running SlimServer, Windows XP, antivirus, firewall, etc.

Take advantage of the economies of scale of computer hardware! There are huge plants devoted to making as much of this hardware as cheaply as possible. One could easily say most of Taiwan's economy is devoted to this. My goodness, I saw a motherboard + Intel Celeron D onboard for $99.99 CDN the other day. While this isn't SOTA computer hardware, this would annihilate most embedded processors and would certainly win in cost/performance.

sander
2007-03-19, 13:27
I'm not so sure it's a poor design choice. Since most of its power is housed in the server, the Squeezebox is the most customizeable, flexible, changeable tech device of any sort available today IMHO.

I agree mostly, my only gripe, that's been somewhat misunderstood here, is that the Squeezebox UI should be a little more asynchronous. It seemed to me this change could be made in firmware and could potentially use LESS processing power and network bandwidth.

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

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.

Robin Bowes
2007-03-19, 14:02
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.

kdf
2007-03-19, 14:04
Quoting sander <sander.2npm001174336202 (AT) no-mx (DOT) forums.slimdevices.com>:


> 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

It's more like:

1. Squeezebox->SlimServer: irport received 7689807f
2. SlimServer: ok, that's the voldown button, looks like that's been
set by the button mapping preferences to be the voldown function for
"common" mode.
3. Slimserver->Squeezebox: send mixer command volume down, send
graphics update for visual feedback of volume change.

However, step 3 could just as easily by any number of alternate
commands depending on which functions have been tied to a volume
change or various player states: synced players, shadowed players,
muted, paused, playing or off, analog or digital volume control,
screensaver state. That doesn't even get into what might happen when
any number of plugins present or future.

Steps 2 and 3 are completely flexible and open source. Jumping from 1
to some specified action (such as a volume change) would be an end run
around that flexible and open source. It would either mean closing
doors and open up a number of issues with those who would want to have
the flexibility back.

Rearranging the architecture, while not impossible, probably isn't
feasible. Tuning performance and improving the latency of the server
is always a goal, but it is also something that is available to anyone
at any time to match their means/needs.
-kdf

MrSinatra
2007-03-19, 14:26
Trying to fit the capabilities of SlimServer into an embedded device would be impossible if it were any less capable than a complete PC.

One could reasonably argue for a "Slimmer" server, or for software architecture improvements to reduce response time, but blaming the client/server architecture doesn't make much sense.

Sean...

can u please speak to this issue a little bit more?

aren't mp3 players (like ipod) basically self contained?

i don't see why putting SS inside the device, (making it fat rather than thin) is such a no go. wouldn't that make it the ultimate cross platform device?

couldn't it be upgraded or given plugins via flashes or some other methodology?

if u had a rack style device, could it not run on linux, host SS, and map drives to wherever ones music is? (or do http) perhaps it could even host some music locally via flash storage.

i'd be willing to pay transporter type prices for such a device.

all, please don't flame me, i'm just asking.

seanadams
2007-03-19, 16:22
Sure you could, but it's just a PC and a Squeezebox in the same chassis. I'm not saying it's a bad idea, just that there's nothing about the client/server architecture that prevents one from doing that right now. Many applications use the model even when both logical things are on the same physical box - why reinvent a less flexible architecture? As far as I can tell, the suggestion to go "less thin-client" comes from a misunderstanding of where the system's potential performance bottlenecks are.

erland
2007-03-19, 16:47
if u had a rack style device, could it not run on linux, host SS, and map drives to wherever ones music is? (or do http) perhaps it could even host some music locally via flash storage.

i'd be willing to pay transporter type prices for such a device.You might, but the problem is that the massmarket user won't. The massmarket user will probably not even be willing to pay the price of the SqueezeBox today.

I think we have a number of different user categories:

Audiophiles:
- Sound quality is everyting, money is no problem. These users will probably pay extra money for a easily maintained server solution, they like to focus on the music and most of them doesn't like spending a lot of time with a computer. If a pre-built SlimServer hardware solution with pre-installed SlimServer was avaialble I suspect many users in this category would go for it instead of maintaining their own PC/NAS box.

The geeks:
- These users often already have their own 24/7 server in the house. Many of the users that experiment with NAS boxes today are probably also in this user category. Most of these users, won't buy a pre-built solution, they like to configure everything themself. The solution here to get better responsiveness is to recommend that they setup a 24/7 running PC server instead of trying to use NAS-boxes. A better multi threaded and slimmer SlimServer might improve the situation a bit for NAS box users, but a NAS box will always feel a bit slow. The reason is that a NAS box is built for being good at serving files and nothing else.

The massmarket users:
- These users don't have a 24/7 server running in their house. They don't want to pay a lot of money for a music streaming device. They don't care much of sound quality, they will probably use 128-192 kbit mp3's. Most of these users will choose to run SlimServer on their desktop computer, which is also used for running games and different kind of applications. Most of these users wouldn't buy a pre-built server that costs $300 extra besides the cost for the SqueezeBox itself, they would instead try to run SlimServer on their already existing Windows based desktop computer. The main problem for these users won't be bad responsiveness, instead it will be a setup that doesn't work at all because they installed the latest game, application or antivirus/firewall. This user category is also the category that will probably cause most support issues.

Todays iPod users is probably in either "The geeks" or "The massmarket users" or somewhere between these categories.

In my opinion any efforts should be focused on "The massmarket users" since this is where SqueezeBox probably have the best potential to grow. As I said in a previous post I think there isn't any easy solution for this user category, mainly because they won't pay a lot of money so the solution must be cheap. The best would probably be to implement better error handling in the installation program and maybe have some additional program that could check the Windows environment and wireless network for different kinds of things that might cause problems.

seanadams
2007-03-19, 17:27
The massmarket users:
- These users don't have a 24/7 server running in their house. They don't want to pay a lot of money for a music streaming device.

Besides not wanting to leave a computer on, the mass market user is not too keen on installing software, ripping CDs, and taking the time to organize a large collection.... but with Squeezenetwork you don't need to do any of that. Personally I almost never access my own music collection now that Rhapsody is available. The home server just becomes a non issue.

nicketynick
2007-03-19, 17:40
Besides not wanting to leave a computer on, the mass market user is not too keen on installing software, ripping CDs, and taking the time to organize a large collection.... but with Squeezenetwork you don't need to do any of that. Personally I almost never access my own music collection now that Rhapsody is available. The home server just becomes a non issue.

Careful Sean, you'll let the cat out of the bag! I love it when you drop hints. Now if only Rhapsody was available in Canada I might understand what you mean............... (hint)

sander
2007-03-19, 20:29
Rearranging the architecture, while not impossible, probably isn't
feasible. Tuning performance and improving the latency of the server
is always a goal, but it is also something that is available to anyone
at any time to match their means/needs.


Wow, thanks for the clarification. I believe you're right given what you're explanation of what happens.

I still do think that special considerations should be taken in to account in regard to the absolute responsiveness of mute and volume in every conceivable situation, since they have an urgency above all other commands in terms of the user experience. But I can see more of the other side now.

Thanks again this helped me understand this much better.

kdf
2007-03-19, 23:07
On 19-Mar-07, at 8:29 PM, sander wrote:
>
> Thanks again this helped me understand this much better.
>
you may want to have a look at the network health plugin; it can give
you messages in the log
flagging any processes that take longer than the timings you set. If
you search on the forum, you'll see it mentioned several times.

one, for example:
http://forums.slimdevices.com/showthread.php?t=32238

-kdf

amcluesent
2007-03-20, 01:11
>The home server just becomes a non issue.<

It would be good if SB4 allowed you to plug-in an iPod and the SB firmware let you navigate it's music and take an analog signal from the iPod's docking connector.

mherger
2007-03-20, 01:20
> It would be good if SB4 allowed you to plug-in an iPod and the SB
> firmware let you navigate it's music and take an analog signal from the
> iPod's docking connector.

Why would you need an MP3 player to play the output of another MP3 player?
There are hundreds of different iPod docking stations out there - quite a
few of them produced by Logitech.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

Bennett, Gavin \(LDN Int\)
2007-03-20, 02:05
>> Personally I almost never access my own music collection now that
Rhapsody is available. The home server just becomes a non issue.

Great if your American - otherwise useless and very frustrating to hear
about.

Hopefuly your tie up with LogiTech will mean you can get Rhapsody like
deals in other countries.


Gavin

If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. http://www.manfinancial.com/home/disclaimer.aspx?DisID=3E4F1 - for important additional terms relating to this e-mail.

valeite
2007-03-20, 02:50
If Rhapsody was available in the UK my order for a SB or a Transporter would be in right now.

Terry

SumnerBoy
2007-03-20, 03:07
Agreed - Rhapsody sounds like a wonderful service, I would definitely be subscribed, however little 'ol New Zealand ain't likely to be included for some time to come...or is it?

wcattey
2007-03-24, 08:19
I've been doing client / server computing practically since it was invented. (Anybody remember MIT's Project Athena?) One of the design principles that I keep seeing people failing to learn year after year, generation after generation is this:

The end nodes ALWAYS get smarter. Make sure your architecture takes advantage of that!

Being a computer geek, I decided that instead of simply buying the gold-plated Sonos system that did exactly what I wanted, I would experiment with the lower cost Slim Devices and Roku solutions to home audio. I've been running the cheapest boxes from Roku (the M500 SoundBridge) and Slim Devices (the SB3) side by side for a while.

Both solutions lack a crucial feature: multi-device synchronized playback. I'd hoped to participate in development of this feature, but other obligations have kept me away from contributing. So I've been a plain user for a while -- watching both systems when they work, and when they don't work.

When they work, BOTH systems are quite nice. Slim Devices, by putting more reliance on the server, and making that open source makes it easier to get new features going, and perhaps to fix problems.

When they don't work, the Roku becomes a brick that you can't debug. The Slim Devices is this thing you can take apart and fiddle with, and maybe get working.

But why do I find myself prefering the Roku to the Slim Devices system?

Because the Slim Devices system, for all its openness and featurefulness, is FRAGILE! It breaks down MUCH more often than my Roku.

What is my experience just as a user? I go downstairs, and exercise to internet radio played directly off my Roku. Then I come upstairs and then begin the process of trying to figure out why my Squeezebox won't play today!

By having the ABILITY to put some brains in the device, and some brains in a server, Slim Devices has a more powerful architecture. By opening up the development, it has the ability to leverage much more talent out in the world. But by putting ALL the brains in the server so that even the most basic things like connecting to someone ELSE's stream, require perfect operation of the device, the server, and a lot of additional festoons in the architecture, Slim Devices has a total solution that is screwed by, not enhanced by, the tradeoff it makes.

If there is ONE thing I would change about the Squeezebox it would be:

Get someone to write some REALLY TIGHT, REALLY ROBUST, stand-alone code for the device firmware that enables it to act on its own without a server. Essentially provide the same stand-alone baseline that Roku does.

-William Cattey
Senior Analyst Programmer
Massachusetts Institute of Technology

mherger
2007-03-24, 09:10
> Both solutions lack a crucial feature: multi-device synchronized
> playback.

You can synchronize Squeezeboxen. I don't know about SB and Roku though.

> Because the Slim Devices system, for all its openness and
> featurefulness, is FRAGILE! It breaks down MUCH more often than my
> Roku.

Hmm... mine just keeps running for weeks, most of the time until I update
to a newer version. No joke. You would have to describe your problems in
more details if you wanted them to be fixed or need help.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

wcattey
2007-03-24, 09:58
You're right to point out that Slim Server has a synchronization feature.

I'd played with it extensively a while ago, and concluded that the implementation would need to be redone in order to meet my needs.

Synchronization works by putting every device in "Pause" before the beginning of each song, and then sending "Unpause" to every device. At computer speeds, you'd think this would be enough, but it really works very badly in practice. It presumes that all devices are similar enough in response to commands, buffering, and latency. The synchronizing page on the wiki points out that you can't sinchronize Softqueeze and Squeezebox hardware.

With internet radio, there is often no detectable song boundary to pause upon, so that implementation simply does not work at all.

When you put a Soundbridge in the mix, it emulates Squeezbox 1, and suddenly all devices end up as much as five seconds out of synch. (I consider this a problem with the Soundbridge emulation, and took it up in the Roku forums.)

To do a proper synch, one needs synchronized time between all devices to at least the milisecond level, the ability to establish, and sometimes correct the latency between when a sound sample is received and when it actually makes it to the ears of the listener, and finally a way to unobtrusively stall a stream, or catch up in silences to bring out of synch streams into synch. This all must be done continuously, is a difficult problem, and is not anywhere near being implemented.

With regards to the failures I've been experiencing, I do intend to query the forum and make use of the excellent Slim Devices community. I would have done so earlier instead of contributing to this thread, but for a while search was not working in the forums. Now that it's back working, I've run out of debugging time for the day. I have set up a new test case, and if that fails, I'll dive in and work the issue.

snarlydwarf
2007-03-24, 10:15
basic problem manifestations like:

waking up Slimserver...
Blank screen

would be able to be traced quickly and easily, rather than to live on as "Is it your wireless hub?" "Is it how much memory your Slimserver host has?".

How would you get any information beyond that?

WOL is "I send a packet to the server.."

If the server doesn't wake up, there are a ton of things that could be the problem, and testing them in software is nontrivial. "Oh, I forgot to enable WOL on the server" or "The Server is unplugged" would test the same. An access point would certainly be awake or the SB would complain about a lack of network. But is it like one of mine that would get stupid sometimes and not feel like passing packets? Maybe. Maybe not.

Maybe it takes the server 5 seconds to wake up.. maybe it is in ultrasleep mode and had tons of stuff running, loading it all back into RAM can take a while...

There really isn't a good way for WOL to know why something isn't waking.

The best option would be for the SB to just keep trying... Maybe a UI change to note, "Retry #6, something is broken" would be useful so people don't keep pressing the Power button, but that's just UI stuff.

Tracing why WOL doesnt work or is slow is something that needs to be done on the sleeping device.

Synching works great for me on my SB's. I don't know why it doesn't work on Roku's, but, then I won't use one.

wcattey
2007-03-24, 10:24
I edited out my description of the problem because I didn't want to clutter up the thread with it. But your info on how the WOL is a really hard thing to debug is helpful.

Mark Lanctot
2007-03-24, 11:47
Nice to see you on the forum, William. Hopefully you do have some time for developing patches/troubleshooting/new features - I'm sure everyone would appreciate the contributions of someone from MIT with the sort of experience you have! :-)


The end nodes ALWAYS get smarter. Make sure your architecture takes advantage of that!

They currently are taking full advantage of the processor, even pushing it beyond its abilities:

http://forums.slimdevices.com/showpost.php?p=188851&postcount=28

Also I hear the firmware is nearly full.

To accommodate extra features, including a barebones server, would either require:

- a lot more firmware space. It's a hardware change so a new device would have to be introduced. Existing owners wouldn't be able to have this. That's the beauty of the existing architecture, all new features added since the SB2 allow anyone with an SB2, SB3 or Transporter to take advantage of it. No obsolescence! This would have to be broken. That'd be a real shame, I didn't realize how important this was until after I got my players. I now have an SB2 that has all the features of an SB3, just a different form factor. This is very unusual and a big advantage when you stop to think about it.

- removing lots of features in the current firmware. Now there are a lot of features and a few codecs I could do without, so that would be fine with me, however this would cause howls of protest from others.

The "server in a Squeezebox" idea keeps coming up but it's currently opposed to the Squeezebox paradigm - the emphasis is on new features and new codecs, which were made easier to implement since the codecs are all in firmware since the SB2. Putting an elementary server in would require substantial firmware rework as well as removal of a lot of these codecs, plus other features.

However things are still being pulled the other way - there are people that would like to see RealAudio, AAC, AAC+, Apple Lossless and Windows Media Lossless added to the firmware. Clearly Slim/Logitech is going to have to start saying "no" and not bending over backwards to support every codec ever developed natively.

In regards to synchronization, there were plans to introduce a fine-grained network clock in 7.0, but I see that's no longer in the software roadmap. Still, as the developers are fond of saying, patches are welcome...if you were to submit code I'm sure it would be well-received given your credentials.

Paul_B
2007-03-24, 13:12
On the subject of syncronisation. Surely to achieve this would require a multicast network than relying on pausing and unpausing at the same time?

snarlydwarf
2007-03-24, 13:24
On the subject of syncronisation. Surely to achieve this would require a multicast network than relying on pausing and unpausing at the same time?

For the time syncs? Probably, though I could envision other problems with it (latency with wireless, for example: since 802.11 is a half-duplex medium, with its own layers of correction, it would be impossible to ensure a packet was delivered to both wired and wireless devices at the same time). That is probably why Sonos doesn't use 802.11 networking, instead using their own protocol.

Reliability or Realtime... can't have both.

Pellicle
2007-03-24, 13:27
I think Wcattey is correct in pointing out that increasing the intelligence in SB is a desirable path forward. That is not to say it should abandon it's roots but technology and competition march on. At the end it is as much of a cost decision as a design philosophy. The current SS capability is partially based on the cost of processing power when designed. Looking at the give and take between distributed computing with PC and centralized computing this can be seen. When the computing power to do a particular application well comes down to levels allowing it to be cost effectively implemented at the point of use it is. IN cell phones you can see applications many said wold never be deployed on a phone platform but today a "smart phone" is a computer capable of handling database, graphics processing, AV processing etc.

The cost to deploy greater intelligence in the SB has decreased significantly since the original design. Memory price has tumbled even more and given the very aggressive memory roadmap will continue to do so for some time. An Ipod nano has up to 8gb of flash today. In another year it will be 16gb. Competition will inevitably push the model of independent device capability. I don't think this precludes the use of SS, syncing or the WEB interface. It merely means the device at a minimum may be able to do more independently or even implement some of the synchronization capability on the devices with one acting as a server. Some MPC players have much of the capability of the SS embedded including sorting and graphics display. This underscores the hardware capability at this price point being available. I think the challenge will be to move forward with more device level capability while not alienating the current base by obsoleting legacy devices.

pfarrell
2007-03-24, 13:48
Pellicle wrote:
> I think Wcattey is correct in pointing out that increasing the
> intelligence in SB is a desirable path forward.

For you, you may say that. For me, no way.
I want a slim device.

I want one smart server and bunches of cheap devices.
I'd be happier if they were cheaper still. Given a choice between
smarter and more expensive and dumb and cheap, I want cheap.

When you have one SqueezeBox, the incremental cost of making it smarter
and better is modest. I've got four. Adding $20 to each is starting to
get to be real money.

If I wanted a home entertainment PC, I would have made one. Instead, I
have bought SqueezeBoxen.

YMMV

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Paul_B
2007-03-24, 15:17
Going down Multicast route I believe meane ditching wireless as inadequate. To achieve quality streaming means, in my eyes, hard-wiring ethernet or ethernet over power cables.

peter
2007-03-25, 00:02
wcattey wrote:
> I've been doing client / server computing practically since it was
> invented. (Anybody remember MIT's Project Athena?) One of the design
> principles that I keep seeing people failing to learn year after year,
> generation after generation is this:
>

Impressive credentials! Welcome to the forum.

> What is my experience just as a user? I go downstairs, and exercise to
> internet radio played directly off my Roku. Then I come upstairs and
> then begin the process of trying to figure out why my Squeezebox won't
> play today!
>

Well, did you figure it out?

Threads like this make me wonder why my 4 SB wireless network just works
and keeps working at least 99% of the time. The 1% is slimserver dying
on rare occasions, hiccups when my wifi network decided to switch to 1
Mbps *once* and occasionally players getting out of sync. The latter is
the most fragile, but I can live with it. I hate the way tracks restart
when you add another synced player, though, couldn't the same thing be
achieved with a short pause in playback?

For the guy suggesting multicast: The SB's buffer minutes worth of
audio, so multicasting seems unnecessary. Perhaps the 'start' command
itself should be multicasted (or simply broadcasted, that would suffice
for 99% of all audio networks).

Regards,
Peter

tbessie
2007-03-25, 02:00
without the help of SlimServer. I mean, how much intelligence is required to read a stream from a URL? It would mean, of course, that there would be two modes of operation, one depending on SlimServer, the other autonomous, and the autonomous mode would be more limited in what it could do, but at least you could have - like the Roku has - space in flash for some URLs and settings and the ability to play them without relying on a separate server.

That in itself would be enough to satisfy me.

- Tim

mherger
2007-03-25, 02:07
> flash for some URLs and settings and the ability to play them without
> relying on a separate server.
>
> That in itself would be enough to satisfy me.

What's wrong with using SqueezeNetwork? You'll need internet access to
listen to radio streams. And as long as you can access the internet, you
can access SqueezeNetwork.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

tbessie
2007-03-26, 01:21
> flash for some URLs and settings and the ability to play them without
> relying on a separate server.
>
> That in itself would be enough to satisfy me.

What's wrong with using SqueezeNetwork? You'll need internet access to
listen to radio streams. And as long as you can access the internet, you
can access SqueezeNetwork.

Untrue - as long as **SqueezeNetwork exists**. I don't want to have to depend on it existing, or being reachable. Some small, basic, generic built-in functionality would be a Good Thing(tm). :-)

- Tim

EnochLight
2007-03-30, 06:33
Untrue - as long as **SqueezeNetwork exists**. I don't want to have to depend on it existing, or being reachable. Some small, basic, generic built-in functionality would be a Good Thing(tm). :-)

- Tim

I digress. I like the ability to log in to Squeezenetwork knowing exactly what services are there at all times, neatly organized, integrated, and guaranteed (sans bugs, for the most part) to work with my Squeezebox. Just supporting any/all Internet radio stations could be potentially chaotic, especially seeing at how quickly Internet radio stations are born and die in the same week at times. Just my 2 cents.