What is Audio Delay set to under the Line-in settings for the Port? Is your system up-to-date?
And set Settings/System/Audio Compression to Uncompressed.
What is Audio Delay set to under the Line-in settings for the Port? Is your system up-to-date?
Hi again.
System is 100% up to date and on S2.
I tried all three of the line-in options with near zero impact.
And set Settings/System/Audio Compression to Uncompressed.
Ahhh ok now that we didn’t see. Thanks Ratty.
Right I don’t have the guitarist to hand but I will link the DVD/CD and test that shortly.
What is happening here Ratty? Why the delay on standard settings? And why is it not optioned to umcompressed?
I’m sure there’s a good reason but if the default option is experience a 3 second delay then surely it would be better that the ‘out the box’ setting is to eliminate that?
Also, possible give a quick heads up on why the options (auto/compressed/uncompressed) are a factor at all? Is that in the manual anywhere? Just keen to understand more and of course to avoid next time.
Cheers
https://support.sonos.com/s/article/1080
https://support.sonos.com/s/article/4838
https://support.sonos.com/s/article/4839
Automatic is the default compression setting. This uses uncompressed, unless network conditions are such that it has to revert to compressed which introduces a delay.
The per-room Audio Delay setting is separate. So for instance one can run uncompressed but with a 2 second buffer with no loss of quality, assuming the source is not delay-sensitive.
Off to have a read and a little education on that right now Ratty. Thanks for sending those.
I’m still struggling a little to understand why the need for the function. Is it due to network performance?
If it is then it’s even more odd in our case as everything is wired in attacama towers. All Sonos runs on decent spec RJ45 and high spec switches. We use wifi only for a laptop and the odd mobile and Alexa type devices.
All the same, time to read up. Many thanks again
Hi again Ratty. OK understand after reading. So it is network performance that causes the delay potentially.
Again in our instance that should be a formality. And is the processing internally on the Sonos device an issue? Would an AMP have a better/larger processor that a Port?
Or put another way, what is the optimum configuration to eliminate the delay? Or is that even possible?
I use Line IN (older AMP) on a TV in gym and I don’t think there is a delay that I’ve noticed. Certainly not 3 seconds.
Just set the compression to Uncompressed, and the audio delay in the per room settings to the lowest value.
FWIW, the delay can not be completely eliminated, just reduced. There is a certain amount which is required for Sonos to ensure that the input can be played in sync across all connected ‘rooms’
All analog line in devices would react in the same manner. ratty’s suggestions would reduce it to the minimum possible, but it will never be zero delay, no matter which device’s line in is being used.
FWIW, the delay can not be completely eliminated, just reduced. There is a certain amount which is required for Sonos to ensure that the input can be played in sync across all connected ‘rooms’
All analog line in devices would react in the same manner. ratty’s suggestions would reduce it to the minimum possible, but it will never be zero delay, no matter which device’s line in is being used.
Yes I’m beginning to understand that reality but still not quite understanding the ‘why’ of it.
Any line-in’s I stick through the Ax10Ai are instant, zero lag or at least so minimal that it’s not perceivable. . And indeed the same for the networked later Pioneer equivalent we have.
It is only when the Sonos box comes into the equation that this significant lag occurs.
Is great to know about the uncompressed and audio delay room options and I will of course set those correctly. I’m sure things will improve. And if we have to accept the result after that then so be it. I’m still a happy Sonos user.
But would be nice to get an understanding as to the why. Processing power? Network design? Something else?
Just set the compression to Uncompressed, and the audio delay in the per room settings to the lowest value.
Yes will be doing that Ratty. I’m sure that will be a big improvement and new Sonos stuff I didn’t know about before.
FWIW, the delay can not be completely eliminated, just reduced. There is a certain amount which is required for Sonos to ensure that the input can be played in sync across all connected ‘rooms’
All analog line in devices would react in the same manner. ratty’s suggestions would reduce it to the minimum possible, but it will never be zero delay, no matter which device’s line in is being used.
Yes I’m beginning to understand that reality but still not quite understanding the ‘why’ of it.
Very simple. Audio data is digitised and sent as network packets.
On a local network these usually arrive at the destination device almost instantly. The key word here is “almost”.
Since the network is shared there are competing bandwidth demands, sometimes resulting is a packet being fractionally delayed. In order to allow for this “packet jitter” there has to be a small amount of buffering at the destination.
Audio data arrives into a short queue and is played out the other end. The length of the queue -- the buffer depth -- needs to be set such that it never runs out of data. If it did the audio would drop out.
You configure the buffer depth in the Audio Delay setting. Set it too low, on a busy network, and the audio would falter.
FWIW, the delay can not be completely eliminated, just reduced. There is a certain amount which is required for Sonos to ensure that the input can be played in sync across all connected ‘rooms’
All analog line in devices would react in the same manner. ratty’s suggestions would reduce it to the minimum possible, but it will never be zero delay, no matter which device’s line in is being used.
Yes I’m beginning to understand that reality but still not quite understanding the ‘why’ of it.
Very simple. Audio data is digitised and sent as network packets.
On a local network these usually arrive at the destination device almost instantly. The key word here is “almost”.
Since the network is shared there are competing bandwidth demands, sometimes resulting is a packet being fractionally delayed. In order to allow for this “packet jitter” there has to be a small amount of buffering at the destination.
Audio data arrives into a short queue and is played out the other end. The length of the queue -- the buffer depth -- needs to be set such that it never runs out of data. If it did the audio would drop out.
You configure the buffer depth in the Audio Delay setting. Set it too low, on a busy network, and the audio would falter.
Is simple now Ratty 
…. not sure it was until 5 mins ago.
No it is obviously clear to you Ratty but not to 90% of us “users with a healthy interest”. And it’s really good to have it explained as you have done so here.
I built our Sonos onto a (very high spec at the time but now fairly commonplace) gigabit network with pretty much the best and simplest of everything. It’s GB & minimum Cat5e (upwards) and business grade Netgear switches. And were we do use wireless, I just put in a top end Orbi 3 satellite system which I should say is amazingly good.
But all that is pretty much irrelevant if I understand you correctly. You are on about the protocols of the digitised music and it’s subsequent relationship with movement of that data and the Sonos mesh network and to a much lesser extend the cables and boxes.
Thanks for the explanation. So we cannot improve any hardware but we can improve settings with that new understanding.
If we can get that delay down from the near 3 second level we experienced to 0.3 of a second then the streamed ‘live music’ we were attempting to do becomes possible …. most likely with monitor earphones rather than live feed.
In reality, this is the same as is experienced in large live music events …. where the sound projected to audience is way behind the stage sound where of course they use monitor speakers. Just our set up being a tad smaller than Coldplay's :-)
Follow the advice already offered to reduce the delay to 75ms, which is as low as it can go with Sonos.
For streaming across any asynchronous network -- where packets are sent when they’re ready, and can get delayed -- there simply has to be a playout buffer of some size at the receiving station. Sonos found that 75ms was the minimum they could get away with for stable Line-In play in a typical local network, especially where it contains a wireless element. In your all-wired situation the buffer could conceivably be reduced substantially from that figure, but yours is an edge case.
Any line-in’s I stick through the Ax10Ai are instant, zero lag or at least so minimal that it’s not perceivable. .
It is only when the Sonos box comes into the equation that this significant lag occurs.
That is because those units must be standalone, and not called upon to also play the signal supplied via the line in to other speakers, wirelessly and in perfect sync.
Sonos assumes that this is a needed feature even if the feature is not being used, or if there is just one Sonos unit installed - the minimum delay to allow for the use of this feature will still occur.
