Answered

Audio Cutout - but only when sourcing from playbase or playbar

  • 17 February 2018
  • 32 replies
  • 953 views
Show first post
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

32 replies

K
Userlevel 1
Badge
Noooooooooo!

Here's my new diagnostic, cut outs are back...that didn't take long after posting the contrary.

457335493

K
K
Userlevel 1
Badge
This was a great explanation of STP - stick with it and it all comes together.
https://www.youtube.com/watch?v=IAIsFX1XPHo
One of the points it made was that I should get all of my SONOS devices on the same switch...I'm not sure my plans can accommodate that requirement. I'll move the connect:AMP to the switch in the other closet and see if my issues resolve.

The next Q would be how to make that not necessary...as I intend to have a stack of connect:Amp in the A/V media closet - but everything else is connected in the main networking closet on the other side of the house 😞.
K
Userlevel 1
Badge
I seem to have stumbled onto a change - which may explain why I thought it was working for a while.
It's only the single wireless Sonos:One that is skipping now (all other devices are hard wired) and I think are OK.
When I ping any of the wired units, my time averages under .300 ms.
However when I ping the lone wireless IP, I think it shows latency during the cut-outs.

Here's a snippet from a ping to the wireless unit:
64 bytes from 192.168.5.243: icmp_seq=25 ttl=64 time=3.374 ms
64 bytes from 192.168.5.243: icmp_seq=26 ttl=64 time=276.656 ms
64 bytes from 192.168.5.243: icmp_seq=27 ttl=64 time=68.874 ms
64 bytes from 192.168.5.243: icmp_seq=28 ttl=64 time=4.352 ms
64 bytes from 192.168.5.243: icmp_seq=29 ttl=64 time=12.398 ms
64 bytes from 192.168.5.243: icmp_seq=30 ttl=64 time=1.924 ms
64 bytes from 192.168.5.243: icmp_seq=30 ttl=64 time=16.952 ms (DUP!)
64 bytes from 192.168.5.243: icmp_seq=31 ttl=64 time=9.463 ms
64 bytes from 192.168.5.243: icmp_seq=31 ttl=64 time=20.021 ms (DUP!)
64 bytes from 192.168.5.243: icmp_seq=32 ttl=64 time=14.857 ms
64 bytes from 192.168.5.243: icmp_seq=33 ttl=64 time=1.654 ms
64 bytes from 192.168.5.243: icmp_seq=34 ttl=64 time=4.948 ms
64 bytes from 192.168.5.243: icmp_seq=35 ttl=64 time=34.500 ms
64 bytes from 192.168.5.243: icmp_seq=36 ttl=64 time=1.018 ms
64 bytes from 192.168.5.243: icmp_seq=37 ttl=64 time=0.999 ms

K
K
Userlevel 1
Badge
Defect appears to be isolated now to the single speaker which is not hardwired.
I was able to follow the Sonos guide to configure STP on my managed switch.
Was kind of a pain tracing all of the Sonos connected wires to the exact ports but finally got it sorted.
The lone wireless Sonos is the only one experiencing the cutout - it's identified port is the same as the Playbase:Living which I think tells me that it's not actually using my WAP, which is on a different switch - but instead is being tunneled across Sonos:Net and through the Playbase hardwire connection.
If that's true, then I've successfully isolated all of the Sonos devices to the managed switch and configured STP for those ports and restarted the switch.

I switched the connect:AMP back to the unmanaged switch to see what would happen.
No change, only the wireless Sonos:1 experiences cut-out.

I think I'll move that Sonos somewhere and get it wired, adjust it's port setting and see what happens...
K
Userlevel 1
Badge
No cut outs when wired...

Here is a diagnostic with everything wired: 753391532

Here is a diagnostic with the Play:1:Kitchen (R) wireless: 1656533661

Any help is appreciated with the analysis.

K
K
Userlevel 1
Badge
I think we've got it! My wifi was on channel 6 and my Sonos was on channel 6, also one of my neighbors is on channel 6 - and I think he's got some Sonos...
I left my Sonos on channel 6 and moved my WIFI to channel 11.
I think I'm good - been listening for a while and all is good.
We'll see if it holds for some college basketball watching...
K
Userlevel 1
Badge
And just to double check...the ping times to the wireless unit are much improved and consistently under 2ms!

64 bytes from 192.168.5.235: icmp_seq=30 ttl=64 time=0.998 ms
64 bytes from 192.168.5.235: icmp_seq=31 ttl=64 time=0.962 ms
64 bytes from 192.168.5.235: icmp_seq=32 ttl=64 time=1.531 ms
64 bytes from 192.168.5.235: icmp_seq=33 ttl=64 time=1.054 ms
64 bytes from 192.168.5.235: icmp_seq=34 ttl=64 time=1.065 ms
64 bytes from 192.168.5.235: icmp_seq=35 ttl=64 time=0.965 ms
64 bytes from 192.168.5.235: icmp_seq=36 ttl=64 time=0.987 ms
64 bytes from 192.168.5.235: icmp_seq=37 ttl=64 time=0.986 ms
64 bytes from 192.168.5.235: icmp_seq=38 ttl=64 time=1.242 ms
64 bytes from 192.168.5.235: icmp_seq=39 ttl=64 time=0.976 ms
64 bytes from 192.168.5.235: icmp_seq=40 ttl=64 time=1.284 ms
64 bytes from 192.168.5.235: icmp_seq=41 ttl=64 time=1.513 ms
64 bytes from 192.168.5.235: icmp_seq=42 ttl=64 time=1.255 ms
64 bytes from 192.168.5.235: icmp_seq=43 ttl=64 time=1.323 ms
64 bytes from 192.168.5.235: icmp_seq=44 ttl=64 time=0.904 ms
64 bytes from 192.168.5.235: icmp_seq=45 ttl=64 time=1.230 ms
64 bytes from 192.168.5.235: icmp_seq=46 ttl=64 time=1.208 ms
64 bytes from 192.168.5.235: icmp_seq=47 ttl=64 time=0.962 ms

K
Terms & ConditionsCookie settings