Answered

Audio Cutout - but only when sourcing from playbase or playbar

  • 17 February 2018
  • 32 replies
  • 950 views
K
Userlevel 1
Badge
I have a playbar on one tv and a playbase on another tv, also several other play:1 play:3 and connect:Amp.
When I use my phone or laptop as a source and switch to 'party mode', everything is perfect - always.
When I watch either TV with only it's playbase or playbar - it works flawlessly.
If, however, I attempt to group any other speakers to either the playbase or playbar sourced by TV sound - the audio cuts out every few seconds. This just started fairly recently - I recall watching some football this way (party mode) with no issues the entire evening - but by the time playoffs rolled around - it's not usable in that way. I'm unable to think of any significant changes that have been made since I recall this working - maybe the playbase is that new - it arrived on christmas day. :)

Another interesting thing to note is that the source playbase or playbar (depending on which tv I want to broadcast) never cuts out - only the satellite grouped speakers cut out - and they all cut out together.

This occurs with 'smart app' sourced audio as well as DTV sourced audio - I'm quite confident it's not a tv/receiver audio output issue in that the two setups are completely different but are behaving identically - also - the 'main' speaker never cuts out.

I tried switching between BOOST and home wifi - no change.
Only a single play:1 is not hardwired to the Gigabit Cat6e LAN.
I tried disabling the wificontrol - no change.
External interference is unlikely - I don't have many neighbors nearby.

I ran the diagnostics: 8505842
Currently playing Netflix Smart TV App in Master Bedroom - grouped in party mode and cutting out everywhere but MasterBedroom Playbar.

Associated ZP: 192.168.5.235
---------------------------------
PLAY:3: Bathroom
Serial Number: B8-E9-37-D0-90-8A:1
Version: 8.3 (build 40549090)
Hardware Version: 1.8.1.3-1
IP Address: 192.168.5.172
WM: 0
OTP:
---------------------------------
PLAY:1: Kitchen (L)
Serial Number: 5C-AA-FD-4D-FE-A2:F
Version: 8.3 (build 40549090)
Hardware Version: 1.8.3.7-1
IP Address: 192.168.5.235
WM: 0
OTP:
---------------------------------
PLAY:1: Kitchen (R)
Serial Number: 5C-AA-FD-4E-01-F2:D
Version: 8.3 (build 40549090)
Hardware Version: 1.8.3.7-1
IP Address: 192.168.5.243
WM: 0
OTP:
---------------------------------
PLAYBASE: Living Room
Serial Number: 5C-AA-FD-32-F1-5D:8
Version: 8.3 (build 40549090)
Hardware Version: 1.14.1.11-1
IP Address: 192.168.5.196
Audio In:
WM: 0
---------------------------------
PLAYBAR: Master Bedroom
Serial Number: 5C-AA-FD-17-9A-19:D
Version: 8.3 (build 40549090)
Hardware Version: 1.9.1.10-1
IP Address: 192.168.5.241
Audio In: Dolby Digital 2.0
WM: 0
OTP:
---------------------------------
PLAY:3: Office
Serial Number: B8-E9-37-DC-5C-42:8
Version: 8.3 (build 40549090)
Hardware Version: 1.8.1.3-1
IP Address: 192.168.5.208
WM: 0
OTP:
---------------------------------
CONNECT:AMP: Patio
Serial Number: 5C-AA-FD-EA-20-AE:D
Version: 8.3 (build 40549090)
Hardware Version: 1.17.3.1-1
IP Address: 192.168.5.60
WM: 0
OTP: 1.1.1(1-17-3-2.1)
icon

Best answer by kphagen 19 February 2018, 21:16

View original
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
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
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
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
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
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
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
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
It's been a week and no issues!
#closed
K
Userlevel 1
Badge
Not sure how many times in my life I need to learn this lesson, but clearly it was at least one more time.
I paid someone to set up my network for me and I think I just invested the same amount of time in unraveling it and understanding it enough to know they did some dumb stuff - but it sure does look neat, tidy and tight! :)

So, to recap, the skipping kept coming back anytime I enabled my unmanaged media closet switch - which in turn would bring the two WAPs online. If I disconnected the two WAPs, all was well - but when either one or both of them were plugged in - I'd start to get cut outs. I'm still baffled as to why this only occurred when audio was sourced from the playbar/playbase AND when a connect:AMP was online.

Anyway, I was unable to gain access to my main router and wap manager (sigh - they make "support" sound so good when they're selling it and you're tired of messing with it). But, what I could get into was my managed Netgear GS748T. After reading this thread, https://en.community.sonos.com/troubleshooting-228999/sonos-and-netgear-managed-switch-6761940/index1.html#post16199215 , I decided to give it a try.

It appears to be in direct conflict with the guidance being offered by Sonos documentation which writes a fairly confusing novel as to how one should Enable STP. This guy very clearly lists it out in a few steps.
Boom! No cut outs, WAPs back online - everything is on.

My initial settings on the Netgear 748T (when it was not working):
Spanning Tree State: Enable
STP Operation Mode: RSTP
Forward BPDU while STP Disabled: Disable

After making only the following changes - my issue was resolved.
Spanning Tree State: Disable
STP Operation Mode: STP
Forward BPDU while STP Disabled: Enable

I know I don't fully understand STP even though I've read enough that I probably should - so I probably don't know what I'm missing out on - but it doesn't seem to have any side effects at this time.

@Support : Here's my current diagnostic: 1796207156

Kevin
K
Userlevel 1
Badge
Update: Well, that was a bust. Maybe it's one of my downstream media components that's not playing nice with the connect:AMP. I probably should have tried pulled those unessential connections before buying a new switch...
K
Userlevel 1
Badge
Rather than burn any more of my time on it (President's Day is over) - I saw this on sale and will just get the Cisco off my network for good. https://www.amazon.com/NETGEAR-Ethernet-Unmanaged-Lifetime-Protection/dp/B01AX8XHRQ/ref=sr_1_3?ie=UTF8&qid=1519143619&sr=8-3&keywords=16+port+gigabit+switch

It is supposed to arrive tomorrow - so maybe I'll have new news to report by the weekend.
K
Userlevel 1
Badge
Update: That's it, once I powered up the Cisco - the cut-outs kicked back on. I'll work to gain access to the admin of the Cisco and make the suggested modifications - or I'll replace this component with something else - i think i was trying to make use of some spare parts I had lying around...

I think you guys have this scenario in your diagnostic lib already: 8513004
K
Userlevel 1
Badge
Update: I'm still struggling with my router support to review recommended settings - but I've done some more isolation.

I have an AC3100 (xwr-3100) Luxul router and two High Power AC1900 Dual-Band Wireless Access Points (xap-1510).
Also included is a switch that runs most of the home LAN connections: Netgear ProSAFE GS748T

In my media closet is another switch, CISCO sg100-16 (v2). This is the switch that the AMP was using to get on the network. I'm still working to get access to this switch but - here's the update.

When I moved the connect:AMP off of this switch - the problem persisted. However, I then turned the switch off and I'm not getting the audio cut-out. There appears to be some angry talk between the CISCO and the AMP which brings things down.

Here's a diagnostic (success) without the CISCO but with the AMP: 8513952
Keith N
Userlevel 7
Badge +19
Glad to see you are on the phone with support! Feel free to reach out should you run into any other problems.
Keith N
Userlevel 7
Badge +19
Hi there, kphagen. Thanks for posting and welcome to the Community. From what you've posted so far, it seems the best course of action would be to give our support technicians a call to troubleshoot this with you in real time. They are able to work with you in real time through a remote session and get a closer look at what is happening with the CONNECT:AMP.

I see you are working with a Luxul Router, what is the make and model of that router and the switch you are using? Thanks!
K
Userlevel 1
Badge
Update13:
On phone with tech support - they're pretty great btw. Thanks John.

They had me relocate the AMP, so I dropped one of the Play:3 and leveraged the network cable and powercable and switch for that component to take those potential faulty connections out of the mix also.

Next step is I need to review my router configuration with regards to 'Spanning Tree Protocol' before we get to the next level.
K
Userlevel 1
Badge
Update12:
Pulling the plug on the connect:Amp put the system back to good (no audio skips).

One thing to recall - broadcasting music sourced from an iPhone or MacBook is OK with the connect:Amp enabled.
Only when the audio is sourced from either the PlayBase or the PlayBar does the audio cut-out occur.

Help me Sonos Support - you're my only hope!

CONNECT:AMP: Patio
Serial Number: 5C-AA-FD-EA-20-AE:D
Version: 8.3 (build 40549090)
Hardware Version: 1.17.3.1-1
IP Address: 192.168.5.60
WM: 0
OTP: 1.1.1(1-17-3-2.1)
K
Userlevel 1
Badge
Diagnostic (fail) - 8512560
K
Userlevel 1
Badge
Yep - it's cutting out within seconds of the connect:Amp coming on line...
K
Userlevel 1
Badge
Update11:

I hope all of this is helpful.

It's a full on party mode, all components except the connect:AMP are enabled and grouped and playing audio from the direcTV signal sourced from the playBase. No audio cutouts during the last 10 or so minutes.

Diagnostic (success): 8512532

I'm convinced now that when I add the connect:Amp, I'll start hearing a lot of audio cut-outs.
Further, I expect the cut-outs to disappear after unplugging the connect:Amp...

I'll let you know in a few minutes! I'm certain you are all on the edges of your seats by now.
K
Userlevel 1
Badge
Update10:

No issues after adding the second Play:1(wireless) - I'm going to add them (everything) to the group and let it ride a bit longer.

Diagnostic (success): 8512483
K
Userlevel 1
Badge
Update9:

Still going strong after 5 minutes of bringing a Play:1 (wired) to the party. Certainly is making a strong case for giving my Connect:Amp the stink-eye.

Diagnostic (success): 8512430

Plan: I'm going to bring in the other Play:1 (wireless) and at this point I'm kind of expecting it to work fine and pin the tail on that Connect:Amp. If that holds, then the Q is there a specific problem with *my* connect:AMP, or is it something wrong with all of them - or something else entirely 🙂.
K
Userlevel 1
Badge
Update8:
As expected, I don't believe that grouping/ungrouping has any significant impact on this issue. It's been over 5 minutes with no audio cut out.

Diagnostics (success): 8512385

The issue I'm having appears related to either a quantity of devices or a combination of devices (or some specific faulty device). Possibly different components have different 'weights' where eventually the total component weight is too much for whatever the problem is - if that theory is accurate, the connect:Amp is the heavyweight in my setup.

I only have a pair of Play:1's and the connect:Amp left to test with.
I think I should fully expect it to fail if I add the connect:Amp - since it failed previously with that component and just one of the play:3 components.

Plan: I think I'll learn more with this next test if I add one Play:1(wired)
K
Userlevel 1
Badge
Update7:

Interesting - no audio cutouts in over 5 minutes with

playbar + playbase + play:3 + play:3

Diagnostics (success): 8512324

Plan: For this next test, I'm going to keep everything as-is and simply group both play:3 components and see if it holds.
K
Userlevel 1
Badge
Update6:

Adding in the Play:3 does not appear to have broken anything - I was able to enjoy audio for over 5 minutes without any cut-out.

Diagnostic (success): 8512225

For this round, I'm only leaving the playbar/playbase grouped and simply bringing the other units online.

Plan: Adding an additional Play:3(wired) to the mix and will give it a listen, keeping the connect:amp out of the mix for now to see how far I can get. My theory is that adding this 4th component will result in the noticeable audio cut-out issue.
Terms & ConditionsCookie settings