After years of resistance, I now have a TV in the patio dedicated to music videos, to be played there and streamed to other Sonos zones indoors. I am seeing the group break up often, even where all the concerned Sonos units have solid green signal strengths back to Boost.
Line is set to uncompressed; both compressed and the choosing the Airplay device trick does not seem to work; the latter does not fix the lip sync problem caused by the former.
The TV is connected to a Connect in the patio, which is used to initiate a group with the 2 other zones indoors, which are also closer to the Boost than the patio Connect. Often, and usually when I choose to change the video being played, these two drop while remaining as a group, leaving the patio Connect playing on its own. When I add the Connect back to these groups, play resumes on all three zones, and, I suspect, in a more stable manner.
Any ideas as to solutions? If I wanted to wire an ethernet cable from the Patio to the router what would I have to do - one end would go into the jack on the Connect, and the other back to the jack on the Boost? Would that solve the problem?
PS: The TV is connected from its audio analog line outs to the Connect Line in.
Question
Best way to make stable groups
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.
Uncompressed PCM (TV audio) has a transfer rate/speed of 1.411,2 kbps, Spotify of 320 kbps. You would need to wire every unit involved to the router or an ethernet switch to avoid the TV audio being cutting out.
+20To
I have no trouble sending Uncompressed audio across my Sonos systems. Some of the players are wired, some are not, but they are arranged carefully to provide universally good signal paths.
I didn't say otherwise. However, uncompressed audio is .wav, and .wav is demanding bandwidth.
+20Respectfully, I didn't say you did.
I'm well aware of the nature of the 'Uncompressed' stream. Note that dropout problems are normally not due to the bandwidth required, but are due to the very shallow 75ms buffer that is used for 'Uncompressed'.
My experience on the German board told me that TV audio is indeed "heavier" than other Line-In sources, it tends to cut out quickly and more frequently. Neither the Connect nor the Play:5 is designed to meet this challenge.
+20How, though? TV audio is 100% identical in nature to any other analog line level audio source presented at a Sonos Line-In input. The bandwidth requirements for Uncompressed audio distribution are identical, and the buffering is identical.
If you think otherwise, I'd like to understand your argument.
As far as I understand this, the input at the line in is nothing more than a signal voltage. And in this case, the TV manual specifies this to be 0.5 volts rms. Which is on the low side compared to that from CD players or DACs that have more than a volt rms.
So if at all, the TV output is "lighter", but I am sure that this attribute isn't what the Support chap meant. So, what DID he mean?
How does the Connect even know that this is from a TV??
So if at all, the TV output is "lighter", but I am sure that this attribute isn't what the Support chap meant. So, what DID he mean?
How does the Connect even know that this is from a TV??
TV audio is indeed no different from any other audio as far as Line-In is concerned. Analog signals arrive. They're digitised as PCM (if Uncompressed) and packetised for transmission. No increased "heaviness" at all.
@Kumar's response from front line support was surely the standard "you should be using a Beam, Playbar, etc." for TV.
@Kumar's response from front line support was surely the standard "you should be using a Beam, Playbar, etc." for TV.
+20So if at all, the TV output is "lighter", but I am sure that this attribute isn't what the Support chap meant. So, what DID he mean?
How does the Connect even know that this is from a TV??
The input voltage level is relevant to the audio volume, but is irrelevant to the WAV encoding and to the bandwidth requirement. It is neither lighter nor heavier. Complete silence still uses the full bandwidth.
The Connect has no way of determining from what device it's receiving an input signal.
This being the internet, this discussion could get sidetracked onto whether TV audio signals are different in some "subjective" way from other line-level analog audio. Let's not.
If you think otherwise, I'd like to understand your argument.
I don't know. I presume if I were a Sonos employee I'd be in the know.
We've already accounted for the Sonos employee's response. Their script could well say "buy a Beam etc" for TV.
But the comment about "weak and old Connect" made me do another experiment that started promisingly, but failed to show much change. I wired a Boost to the Connect LAN port, and after making the Play 1 revert to root bridge, the matrix showed me:
- Boost communicating to Play 1 as a secondary node, in green
- Connect as a tertiary node, but all grey across its tunnel
- All other units communicating like the Boost in 1 above, all in green.
I think pwt has it right - this is less a bandwidth and more a shallow buffer issue. Why does it have to be shallow? And by the way, designating the line in source as Airplay device did not work because it did not address the lip sync issue.
Uncompressed has a shallow 75ms buffer, to try and maintain lipsync. Compressed is a couple of seconds. 'Airplay Device' with Uncompressed uses a 500ms buffer. With Compressed it possibly adds another half second to the two secs.
If daisy-chaining the Connect off the Boost fixes things it suggests that either the Connect's WiFi card is not performing as well as the Boost (Boost is better tech anyway) or the unit is somehow in a less than favourable position.
If daisy-chaining the Connect off the Boost fixes things it suggests that either the Connect's WiFi card is not performing as well as the Boost (Boost is better tech anyway) or the unit is somehow in a less than favourable position.
Ok, so that tells me why "Airplay device" messes the TV experience; and the fact that the uncompressed shallow buffer is there to maintain lipsync gives a sort of indirect explanation for the "TV audio is heavy" parroting that seems to be common. It is only heavy because to achieve lip sync not required with other sources, the buffer has to be shallow, making the source heavy in relative terms.
The Boost Connect daisy chain experiment worked well only for a short time; stuttering resurfaced.
Hopefully, the patch cable solution works and I can then install a permanent one between the Connect and the core network.
The Boost Connect daisy chain experiment worked well only for a short time; stuttering resurfaced.
Hopefully, the patch cable solution works and I can then install a permanent one between the Connect and the core network.
I appreciate that your matrix tunnels are green, but what about the column on the left?
They use point-to-point 5GHz locally to surrounds/sub, and can therefore manage to reduce buffer size to ~30ms. However for grouped play with other rooms they're back onto 2.4GHz, with the ~75ms buffer. Grouped rooms are therefore slightly behind.
It's also been observed that a lightweight lossy compression is applied to TV audio sent to grouped rooms, though I've not checked this out myself.
The column on the left does not look nice; probably because the Firestick that supplies the TV via WiFi is, as it as to be, in the vicinity. But I thought the Boost does a better job of dealing with such interference than Connect can.
In any case, this becomes moot once the Connect is wired to the network - the Connect could be red and it would not matter where the group was limited to network wired speakers?
In any case, this becomes moot once the Connect is wired to the network - the Connect could be red and it would not matter where the group was limited to network wired speakers?
Ah, that might well be a factor. Have you tried the Firestick on 5GHz?
In any case, this becomes moot once the Connect is wired to the network - the Connect could be red and it would not matter where the group was limited to network wired speakers?
It wouldn't matter, and once wired I'd probably opt to disable the Connect's radio.
It's also been observed that a lightweight lossy compression is applied to TV audio sent to grouped rooms, though I've not checked this out myself.
So the 75 ms buffer must make a similar challenge for stable grouped play. And the Sonos response THEN must be - wire all the speakers in the group to the network - being unable to trot out the "buy a beam" response.
It's also been observed that a lightweight lossy compression is applied to TV audio sent to grouped rooms, though I've not checked this out myself.
Speculation! But as I say I think the bandwidth for TV sound sent to grouped players by an HT player (Beam etc) is less than PCM. Someone on this board did some tests a while back.
On installing the patch cable and disabling WiFi on Connect, I have the expected results, but I was hoping that a larger group will also play well; it does not.
Cut/paste from an email therefore sent to Support, if anyone here has any insights, without the access to the diagnostics information that only Sonos has now:
Quote:
Can you help me with at least some review of the diagnostics, if you can't do more for me? Because only you can do this now, with much information that we could see earlier, no longer there for us to see in the Matrix.
I have now wired the Connect to the same router to which the root bridge play 1 is wired. While the play 1 is now playing fine in a group with Connect, another wireless member of the same group, Living Room, is stuttering: Diagnostic 1269669520
What is wrong now? with the Connect WiFi also disabled, its "age" as you call it, should not be a factor.
Now I replaced the Living Room with the Dining room play 1 pair, and things seem to be ok: Diagnostic 315553685
What is different from the earlier case, that this group plays ok?
And then, with another speaker, Play 1, added to the aforesaid group, so that the group now has 4 members, and is playing ok: Diagnostic 982479128
Hopefully these specific questions for each diagnostic now being sent, will yield specific, and therefore more useful, answers.
Unquote
Cut/paste from an email therefore sent to Support, if anyone here has any insights, without the access to the diagnostics information that only Sonos has now:
Quote:
Can you help me with at least some review of the diagnostics, if you can't do more for me? Because only you can do this now, with much information that we could see earlier, no longer there for us to see in the Matrix.
I have now wired the Connect to the same router to which the root bridge play 1 is wired. While the play 1 is now playing fine in a group with Connect, another wireless member of the same group, Living Room, is stuttering: Diagnostic 1269669520
What is wrong now? with the Connect WiFi also disabled, its "age" as you call it, should not be a factor.
Now I replaced the Living Room with the Dining room play 1 pair, and things seem to be ok: Diagnostic 315553685
What is different from the earlier case, that this group plays ok?
And then, with another speaker, Play 1, added to the aforesaid group, so that the group now has 4 members, and is playing ok: Diagnostic 982479128
Hopefully these specific questions for each diagnostic now being sent, will yield specific, and therefore more useful, answers.
Unquote
Some strange bits from a email response from Support:
Also did you disable WiFi on one of the connects manually? It can be enabled because it will increase overall performance.
Signal from CD player is in usually compressed digital format but signal from TV is usually in uncompressed format.
Back to square one...with respect to the heaviness of the TV signal!
Also did you disable WiFi on one of the connects manually? It can be enabled because it will increase overall performance.
Signal from CD player is in usually compressed digital format but signal from TV is usually in uncompressed format.
Back to square one...with respect to the heaviness of the TV signal!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.