Skip to main content
Contributor I
May 7, 2016

Line-In Latency/Delay Disable PLAY:5

  • May 7, 2016
  • 193 replies
  • 32092 views
Hey Sonos Engineers!

I know this has been touched upon. I previously submitted this request to support and they encouraged me to share here to keep the conversation going.

Is there any chance we could implement a soft switch for line-in audio to bypass the computer for "delay disable" functionality.

I understand and appreciate the reason for the delay.

However, I'm running turntables through a mixer and into the line-in of the PLAY:5. Can't teach my son to mix records with that delay, and since we're set-up in a communal space, my wife is not too keen on bringing out the old mix monitors. Can you dig it?

Can we figure out a way to manually disable the delay on an individual speaker basis?

Otherwise love the gear!

Thanks!

Here's quote from customer support. Hope it isn't too heavy handed or out of school to post:

"I'm not on the development team, but I personally think that it wouldn't be too hard to implement some kind of soft switch to bypass the computer altogether and pipe line-in audio directly to the amplifiers (something like a computer-controlled solid state IC relay network)."
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.

193 replies

melvimbe
January 8, 2021

 

 

We all know the real reason the line in has delay to it.  You just don’t want to say it.  Products with line-in don’t cost enough, and the latency is your penalty/incentive to buy the more expensive model.  “Don’t be a cheater” says SONOS.  “You need to pay for the expensive home theatre products if you want true line in.  Proles.”  And you better like it too.

 

Line In capable products:

Port - $450

Five - $500

Amp - $650

Move - $400 (if you count bluetooth as a line in capability)

No latency (HDMI-ARC/optical)

Beam - $400

Amp - $650

Arc - $800

 

 

 

Danny
Lyricist III
January 8, 2021

All of these devices have a delay though. Even the HDMI/ARC options have a 30ms delay.

controlav
Lead Maestro
January 9, 2021

All of these devices have a delay though. Even the HDMI/ARC options have a 30ms delay.

No they don't, on digital input, unless you Group them with other devices.

Author of the leading independent Sonos apps for Android, MacOS, iOS, Windows and Xbox.
jgatie
January 9, 2021

All of these devices have a delay though. Even the HDMI/ARC options have a 30ms delay.

 

Member since 2017, just posting now?  Phew, I smell stinky socks.

Lyricist III
January 9, 2021

All of these devices have a delay though. Even the HDMI/ARC options have a 30ms delay.

No they don't, on digital input, unless you Group them with other devices.

Oh, I heard that it was also the case on ungrouped speakers. So this delay-free functionality already exists in the platform.

Then what would the remaining reasons be not to implement this feature?

Ken_Griffiths
January 9, 2021

Some of the reasons I see to not implement a ‘no-delay’ audio feature is the development cost and the lack of any customer demand, relatively speaking ...and perhaps ‘most important of all’ it also goes against the main purpose of a Sonos Audio System, which is first and foremost designed as a multi-room wireless home audio speaker system.
 

The Sonos products are not a speaker for use with a DJ mixing desk, or to use for karaoke. The patented computer-based technology inside a Sonos device would be somewhat irrelevant for that lesser-type of functionality and I guess many other manufacturers would (and do) make a similar sounding speaker cheaper for that ‘limited-only’ purpose. 
 

Sonos is geared towards quite a niché market area and I personally think they should continue to  concentrate their development efforts in that area, rather than perhaps trying to be "all things to all men”… er … and women.

Lyricist III
January 12, 2021

Hey @Ken_Griffiths, you don’t need to go against this (yet) again. It has been said and countered multiple times. Using development costs as a reason not to build something is just a fallacy. The more so if the functionality already exists in the platform. It’s a matter of priority.

 

Yes, Sonos is a multi-room wireless home audio speaker system. Yet they’ve gone into homecinema, added a mobile speaker with bluetooth, added line-in and added the no-delay functionality. Because they apparently thought it was worth the effort, it’s not up to us to decide that for them.

 

This is a feature request to expand the no-delay functionality to the analog inputs.

January 12, 2021

...and added the no-delay functionality. Because they apparently thought it was worth the effort, it’s not up to us to decide that for them.

As a purely technical comment, i do not believe they have introduced ‘no delay’ anywhere.  I believe (although I am not 100% certain) that the 30ms lag is to allow the main HT speaker (e.g. Arc) to sync with the Sub / surrounds.  30ms is not detectable by the brain as far as lip sync issues are concerned.  The connection used is direct routing over 5GHz, because this allows latency as low as 30ms.  I aloo believe (but am not 100% certain) that this delay also applies when the HT speaker is used without Sub and speakers.  That would be consistent with having a lag on the line-in on a Play:5 even when not grouped.

If the HT speaker is grouped with other speakers for music, the 75ms lag is needed to sync perfectly, as it is for any other speaker.  

 

All of these devices have a delay though. Even the HDMI/ARC options have a 30ms delay.

So I think you were right in the first place.

January 12, 2021

@by7 - I have read some insane suggestions and conspiracy theories on this forum, but I don’t think your contributions will ever be beaten for sheer, jaw-dropping craziness.

ratty
January 12, 2021

Indeed. The 30ms for HT setups is there in all configs. There has to be some finite playout buffer on an asynchronous network to allow for packet jitter. The tight 5GHz coupling allows this to be reduced to 30ms from the 75ms minimum requirement on the shared 2.4GHz.

 

As for 

Using development costs as a reason not to build something is just a fallacy. The more so if the functionality already exists in the platform.

(a) the functionality -- a direct pass-thru -- doesn’t already exist, and (b) the idea that costs have no bearing on business decisions is quite simply risible.