Feature Request - Negative delay for Sonos Port

I believe Sonos is about sound, so removing any (extra) processing an amp would do is superfluous.

Having said that, what is your use case? I believe you want to have your amp, connected to a Port, play in sync with other Sonos devices? How would setting a hard “negative delay” work, when the time taken to process the sound might be different from amp to amp and between settings on what processing you think is necessary?

I assume that you are discussing the SONOS Line-In latency. Eliminating this latency would risk audio interruptions due to small network delays resulting from wireless interference or heavy traffic. The latency allows SONOS to ride through relatively minor issues without interrupting the audio.

I believe the OP is talking about the delay added by some receivers due to DSP processing of the incoming signal from the Port.  The request, I assume, is to be able to apply a delay to all other Sonos devices in a group, so they will be in sync with the Port output + DSP delay of the receiver.  If this is so, it poses some logistical questions:

So what happens to the sound when the Port is added/removed from a group?  Should the other speakers in the group go from their standard delay to a longer delayed buffer, thus causing a dropoff in sound, in order to accommodate the newly added Port’s downstream delays?  Similarly, when the Port is removed, should the track skip ahead to eliminate the delay which was added for the Port? 

Also, the delay effect for downstream receivers can vary according to the amount of processing required for each DSP being applied.  How do you compensate for the difference between passthrough/”True Stereo” type limited processing and something which requires a more significant delay? 

So, lets say I have 3 sonos devices, one of which is a sonos port connected to an AMP, and the AMP plays the audio through a 5.1 surround sound system.  The AMP will add a delay for the processing (to clean up sound and split amongst the speaker array, etc). 

When the Sonos Port is part of an audio group with the other 2 devices, the Port will sound out of sync due to the delay coming from the AMP.  The way I see this working, is in the settings for the Sonos Port, a new option would be added for output delay compensation (aka negative delay).  A user would then be able to adjust the slider up as needed to add ‘negative delay’ to the settings for the Port.

When the Port joins a group (or is removed from the group) this delay value needs to be registered to the group, and the other speakers in that groups should apply that added delay to each speaker. So in this scenario.  So lets say the user has manually configured this new “output delay compensation” value to 60ms.  When the Sonot Port joins a group with two other speakers, both of those speakers would automaticaaly add on 60ms delay to themselves.  Now those two speakers and the output from the AMP would be in sync.  Since an AMPs delay would be a static amount, the user really only needs to configure this setting on the port one time.

So you are proposing a group inserts a skip into the stream when a Port is added to a group?   

And how long do you think it will take before this forum is screaming about their music skipping whenever they add in the Port?  I’ve got news for you, it won’t be long.  

Either way, as you stated this has been requested for a long, long, time.  It has never been implemented, more than likely for the problems stated very clearly here and in those long closed threads (incidentally, threads are closed after a period of inactivity, regardless of the subject).  I would not expect things to change on this issue. 

Yes, if a user has configured a delay compensation (negative delay) value on the Sonos Port, the other speakers in the group would have a slight pause when the Port joins the group when they increase their output delay.  And they would also slightly skip ahead when the Sonos Port is removed from the group and that delay is removed. Keep in mind, this would only happen when the Port is added/removed from the group.

Currently, my Port changes the receiver automatically to it’s “sonos” input when audio is detected, and that is always set to whatever setting. I do not think users would be flipping between DSP modes regularly once they have this configured. If they change it, and the DSP delay changes, they woul dneed to update the slider on the Port’s settings (the new setting I mentioned) to accomodate their change.

A slight skip would only occur if a negative delay was added. Users who don’t have a need for this delay would not experience any skip in sound. Also, under the setting, adding in a one line message that outlines this if the setting is used, would be all that’s needed. Users would be aware of what they are adding if they adjust that setting.

Interesting idea, not sure how big the target audience is though.

Given my experience with a couple different AVRs you would need a programmable delay interval and maybe need to change it, not only for different AVRs but if your music processing modes/settings change on a single one. 

All things which have been proposed before, for this and other “make an exception for XYZ functionality” issues, like the request to eliminate the Line-In delay when used on a single device.  Suffice to say that Sonos is not a big fan of these types of exceptions, given these “problems” have never been addressed.  Interrupting the smooth transition from a grouped to an ungrouped state (or vice versa) seems to be a big taboo, given the importance of grouping as a function of Sonos’ core multi-room capabilities. 

Well, the target audience would basically be Sonos customers who also have an AVR in their living room and want to utilize those existing speakers as part of their Sonos environment.  I imagine the amount of users using an AVR is not tiny.

So looking at this from an ROI perspective, you have a decent number of potential users who would likely utilize this use case. I know when I search google about the port, you see a number of threads across different sites with complaints about being unable to Sync the port, and that could be a deterent that currently persuades customers from not buying the product.  Having this type of feature would alevieate that complaint and make the product more viable to that market. Also, it is a software update and existing hardware would likely be compatible (though I’m not a Sonos dev so that would need to be verrified). And lastly, with this new value being defaulted at 0, existing users would not be affected and their current Port setups would be unchanged, so it would be an invisible upgrade.

I dare say I can’t remember the last time this subject came up on this dedicated forum (and the useless search facility means any attempt to find out is futile).  Though the latest I’ve found is from 3+ years ago, and it is lameting a request going back “17 years”;

Which doesn’t bode well for any new requests to convince the “powers that be” any differently. 

I forgot to address your second paragraph. Yes, adio gap/skip is taboo, but keep in mind that this would only affect users who wish to utilize this feature, so people not using a Port are unaffected, as are those that use Ports and leave this value at 0.  Purists who do not want any gap/skip would simply not use this delay correction.

The exact same thing was/is said about the Line-In delay being eliminated when used as a standalone player; “it only affects those who wish to use it that way”, etc., etc.  Sonos appears to have decided that the problems which could arise from exceptions like these fringe cases are not worth the juice from the squeeze. 

There’s also the very real software phenomena of users switching something on “just because”; where if a setting/configuration is there, someone is going to turn it on and fudge with it, whether it applies to their situation or not.  The complaints and/or support hours which arise from things like this often times are not worth accommodating the very few people who actually have the problem.

Well line in delay exists, so they’ve allowed that feature. Like I said above, adding a one liner under the setting warning of audio skip/gap when joining/removing this device if this setting is adjusted above zero would at least make users aware.  I can’t speak towards the hours of sonos support for this, do you have any insight into how many hours of support were needed when line in delay was added as a feature?

Line-In latency has been a designed-in characteristic since product introduction in 2005.

You misunderstand.  The request regarding the Line-In wasn’t to add the delay, the delay was there from the get go.  The request was to eliminate the delay if the Sonos device was being used as a “standalone speaker”, for the purpose of a live performance such as Karaoke, public address, or DJ’ing.  (Of course the “standalone speaker” part was tacked on only after the requestor(s) found out the reason for the delay was for multi-room reliability).  This was never implemented, and instead, they just state that Sonos is not suitable for live performance. 

Look, I love my Sonos products, but avoiding new features with real world use cases over speculation on man hours for support on users who might randomly or accidentally turn it on, seems a bit out of the blue. That type of reasoning can be used for nearly any feature from any software in existence and only stands to prevent growth or improvement of the product.

Take “truplay” for example. A user might turn it on by accident and not enjoy the changes to the audio quality of their speaker. Maybe they’ll call support and have to troubleshoot why the speaker sounds off from when they turned it on. Is that reason enough not to implement that feature because someone didn’t know they were turning it on?

Sigh.  I dare say the benefits of Trueplay far outweigh any backlash from users who randomly or accidently turn it on.  It’s also a feature Sonos encourages you to turn on in any circumstances, so they should be supporting it.  That’s a bit different from something they only intend for a bare minority of users, which would be detrimental to the majority of those turning it on out of curiosity or by accident. 

Also, the users complaining about being able to match the DSP delay of their receivers when using a Port are miniscule compared to those who use Trueplay.  The very fact that the last thread on the subject is from 3 years ago tells you the relative urgency of this request. 

Alright, close this thread then.

Before I was into Sonos I owned a succession of Marantz Homecinema receivers that where connected to the CD-player I still use today. Even then, I always used the “Direct” setting to avoid having CD sound pass through unnecessary components. In your use case this would also eliminate the delay.

 When you are playing Dolby Atmos on a Atmos capable room then group in a non-Atmos capable room there is a short muting of the sound.  I think if there was a notification warning of a possible glitch using a delay compensation for a Port users would accept that one time flaw in the music flow.  Group the devices before the party starts.

I’m sure Sonos has far more data on what their users will or will not accept, not to mention what they themselves consider to be reliable streaming performance of their own system. 

Exclude Sonos from use case for a moment, how would a multi zone AVR handle this, if one zone is using a DSP and another is plain stereo?

Could this feature possibly already be implemented on the AVR to cater for this DSP delay, and use the second AVR zone as source into Port (Sonos)?

Some AVR’s will not convert HDMI audio to analog.

In my case, disabling dsp means losing my sub, and the actual speakers are too thin to maintain audio fidelity without the sub integration. Even in pure direct there is enough delay to cause drum beats to sound like an echo when paired in sync with another room.