PDA

View Full Version : Maximum number of hardware devices that can be synced



tandy1000rl
2013-10-16, 13:32
Over the weekend I doubled my Squeezebox ecosystem from 9 Radios to 18 due to moving into a larger house. While I previously had no issues syncing those 9 Radios in the new house, I'm not having much luck getting all 18 to sync and perform reliably. They are all connected via wifi across 3 access points broadcasting on seperate nonoverlapping channels (1, 6, and 11), and each AP is hard-wired with cat6 to one central router.

Syncing the power turns the radios on and off in less than a second--very responsive. Using TheSynchronizer plugin I can select sync groups that take less than a second to occur. However, trying to stream nearly anything with all 18 radios synced in a single group can take 1-2 minutes before anything starts playing. Eventually it does usually work, but anything playlist or play-related remains sluggish (i.e. change the station--wait another 1-2 minutes)

Am I hitting some system limitations in the LMS sync algorithm? My bandwidth seems to be fine, because when I do an internet speed test using a laptop connected to the same wifi, my speeds are a steady 10 Mbps when all 18 radios are streaming in a synced group. With no radios playing, it is a steady 20 Mbps. Plus, 18 radios x 128KB stream = about 2.3 MB of required bandwidth.

I've messed around with all of the sync-related settings in LMS but have not had much luck getting performance to improve. It seems syncing 2-3 radios results in instantaneous playback, and syncing up to 12 results in a 1 second delay, so why does syncing 18 increase the playback time exponentially? I'd be happy with a 3 or 5 second delay, but 1-2 minutes is not going to work.

Have my needs outgrown Squeezebox's capabilities? Any other thoughts on this?

Thanks!

DJanGo
2013-10-17, 07:17
hi,

access points (in most cases) are always "shit"...

The only "good" way to manage Access points is one switch feeds all of them only via LAN.

If any works as a repeater you just get the half of its capacity because he must send the ack from the client back to the server - if that works just over LAN its god - if the backbone is also WLAN he needs the half capacity of it.

And then alway check the channels in fact use different channels on each Accesspoint to limit the traffic Wlan over Wlan!

To find out, whats the weak point get the Clients together in one room.

garym
2013-10-17, 09:01
hi,

access points (in most cases) are always "shit"...

The only "good" way to manage Access points is one switch feeds all of them only via LAN.

If any works as a repeater you just get the half of its capacity because he must send the ack from the client back to the server - if that works just over LAN its god - if the backbone is also WLAN he needs the half capacity of it.

And then alway check the channels in fact use different channels on each Accesspoint to limit the traffic Wlan over Wlan!

To find out, whats the weak point get the Clients together in one room.

The OP said that all the wifi APs are hardwired via ethernet back to a single router. He's not using them as WIFI repeaters.

epoch1970
2013-10-17, 12:01
Have my needs outgrown Squeezebox's capabilities? Any other thoughts on this?
Sorry I can't test.
I surmise that in the group of 18, 12 (or so) get ready to play, but their readiness status expires before the other 6 are ready too, so the whole group is never ready to start…
Have you tweaked settings>advanced>network>Synchronized Players Startup Delay (ms) ?
The help bubble seems promising:
When multiple players are synchronized, Squeezebox Server tells each player to start the track at the same time. It needs to make sure that each player has time to receive the start command before they all start together and so it sends the start command ahead of time and the players each wait until the right moment to start. If there is excessive network congestion, which can happen particularly when there are many players on the network and with wireless networks, then the default delay of 200ms may not be sufficient. You can change the value here if necessary.

Also, if you're dealing with radio streams (playing on the Radios…) I would prefer to have player>player name>Audio>MP3 Streaming Method set to "proxied streaming". The SB server provides superior buffering compared to a player; at least for me, my SB3s, etc.

HTH.

tandy1000rl
2013-10-17, 21:37
Sorry I can't test.
I surmise that in the group of 18, 12 (or so) get ready to play, but their readiness status expires before the other 6 are ready too, so the whole group is never ready to start…
Have you tweaked settings>advanced>network>Synchronized Players Startup Delay (ms) ?
The help bubble seems promising:

Also, if you're dealing with radio streams (playing on the Radios…) I would prefer to have player>player name>Audio>MP3 Streaming Method set to "proxied streaming". The SB server provides superior buffering compared to a player; at least for me, my SB3s, etc.

HTH.

Thanks for the feedback. Yes, I've tried increasing and decreasing the Synchronized Players Startup Delay to no avail. I had been using Direct Streaming, but tried setting it to Proxied for each player and that didn't help either. I can post some logs from player.sync = Debug, but is there another log I can also select to show how LMS is parsing and processing the radio stream?

I do not think it is the network as I'm averaging 2 - 4ms at each of the 18 radios on a ping -t when nothing is playing and the same latency with all 18 synced and streaming. I've backed off the Minimum Synchronization Adjustment (ms) from 10 to 60 and that seems to be the only setting that helps. Local music generally starts playing within 5 seconds about 3/4 of the time. Sometimes it will take up to 30 seconds to hear the sound at the radios (though the timescale slider moves as though I "should" be hearing the audio). And few internet radio stations also start up quickly. But most of the are still taking a full 1 minute or won't start playing at all.

I'm going to try installing LMS on another slightly more powerful machine to see if that does anything for me.

pippin
2013-10-17, 23:40
The server isn't connected over WiFi, isn't it?

You must not make WiFi bandwidth calculations in the form of 18*128kbps....
There is overhead in the protocol itself, at least a factor of 1.5 or 2 and then you've got additional overhead due to collisions over the network which depends on the number of devices on the network, that overhead grows exponentially.

If your server is on the same WiFi network the bandwidth also counts twice since you have to stream from the server to the access point and then back to the radio.

Still... If it was purely a bandwidth thing you should get "buffering..." messages plus using several APs usually is a good mitigation.

JohnnyBAwesome
2013-10-18, 08:44
I could be wrong, but based on what i've read in some other threads in passing, there's always a buffer requirement, and since you have more pieces and each one has its own "internal clock" - it needs as large as a buffer as possible to prevent the players from being out of sync.

Are you stuck with Logitech/can't swap out? Some of my friends have large Sonos setups without any issues (I remember they do a WiFi / "Mesh" network, where the more pieces there are, the stronger it gets? http://www.sonos.com/

pippin
2013-10-18, 09:04
The mesh network has the same bandwidth limitations as other WiFi networks, it would be even worse than the OPs current setup because it will only use a single channel. Have you ever tried to sync 18 devices with Sonos?
If this is really a bandwidth problem over WiFi or on the server side, Sonos will not solve it.

I could still imagine it's an issue with the sync process itself in which case tweaking the startup delays or sync delays might help.

bpa
2013-10-18, 14:56
You should check the TCP statistics (using netstat) for the server ethernet interface and if you see a number of timeout or packet retransmissions just after starting playing on synced players - then you'll know it is a network overload problem.

tandy1000rl
2013-12-19, 16:54
Just an update on this, where I was having playlist startup problems when syncing a large number of Radios through wifi.

I had mentioned that I had 3 APs on the same network, all on separate channels. While rewiring the basement, I turned off one of the APs and noticed that my Squeezeboxes were much more responsive connected to just the remaining 2. In fact, I can now easily sync 15-20 Radios through the wireless network and have any playlist, local or streaming, start within 3 seconds--much better than the 20-60 seconds it used to require. At this point I'm so overjoyed and scared to jinx anything by researching the underlying cause, but I suspect it's due to the de-commissioned AP being connected to the network through a secondary switch (i.e. daisy chained) rather than though the main switch. Or, maybe it was due to the Squeezeboxes constantly looking for and hopping to the strongest AP which really have minimal differentials in most cases.

Ideally, I could tie each Radio to a specific AP, but Logitech does not make this easy with manual (non-DHCP) network configuration settings. Anyway, it's now a pleasure to use the system once again, and I can confirm the sync algorithm is quite robust with 15 - 20 wireless units.

garym
2013-12-19, 17:00
interesting. Thanks for following up.

Mnyb
2013-12-19, 17:41
Just an update on this, where I was having playlist startup problems when syncing a large number of Radios through wifi.

I had mentioned that I had 3 APs on the same network, all on separate channels. While rewiring the basement, I turned off one of the APs and noticed that my Squeezeboxes were much more responsive connected to just the remaining 2. In fact, I can now easily sync 15-20 Radios through the wireless network and have any playlist, local or streaming, start within 3 seconds--much better than the 20-60 seconds it used to require. At this point I'm so overjoyed and scared to jinx anything by researching the underlying cause, but I suspect it's due to the de-commissioned AP being connected to the network through a secondary switch (i.e. daisy chained) rather than though the main switch. Or, maybe it was due to the Squeezeboxes constantly looking for and hopping to the strongest AP which really have minimal differentials in most cases.

Ideally, I could tie each Radio to a specific AP, but Logitech does not make this easy with manual (non-DHCP) network configuration settings. Anyway, it's now a pleasure to use the system once again, and I can confirm the sync algorithm is quite robust with 15 - 20 wireless units.

Actually squeezeboxes are realy bad at roaming between ap's there is no guarantee that one radio is conected to the strongest one ever it probaly connects tot first one it can conect to . Now with only two of the separation may be soo good the radios has less choice and most of them only see one ap reliably and conect to that one .

If you decide to experiment further , you could have the three ap's with different ssid and pass and conect the radios to the one with the prefered strength .

Depending on placement some radios could also be wired , IMO I would use wifi only if a cable where not physically possible.

vining
2013-12-19, 18:04
What type of APs are you using? G or N and if N are you using 40mhz or 20mhz bandwidth? In the US only one N at 40mhz AP fits in the spectrum with the 3mhz seperation between channels. Two APs overlap slightly and can be used with out too much interference but 3 can cause enough interference to severely degrade performance unless you have a really big house with long distances between APs. In large homes requiring multiple APs we almost always use N type APs with 20 mhz channels for this reason. When using two we'll set the most likely used AP to 40 mhz and the second to 20 mhz.

Here's a good link that explains: http://www.connect802.com/80211n_channels.htm

yeomanspc
2013-12-20, 17:04
We used to have a stack of issues with WAP handovers (Netgear WAPs), then got some cisco WAP 121 access points - initially to address some issues with Apple connectivity. These devices have some kind of co-ordination (clustering) so that they communicate with each other (and single point setup). We get far fewer drop-outs now, especially when wandering round the house with mobile tablets etc.