Delay compensation when used with AV receivers

Easily overcome by having the settings available through a "secret" menu - maybe browser based e.g. xx.xx.xx.xx:1400/avdelayconfig.htm rather than even having to go via a controller? Assuming of course that this would usually be used by expert installers and wouldn't need constant adjustment.

Thanks Gaz. Anticipating an objection to differentiating a DIY vs dealer feature (something which I assume Sonos wants to avoid or they wouldn't be making such a DIY pitch in their marketing) it could also be avoided with a couple more sentences in the controller page I described before.

"This rooms sound lags behind the rest of the house by xxx milliseconds (default: zero)" then even if someone DID stumble upon it, there is ZERO likelihood that, absent some problem they've noticed, that they're going to think, "Oh, I should really go and adjust this setting for the hell of it".

Let's say even THIS control only popped up after a screen that says, "Some receivers and home theatre systems take a few fractions of a second to process audio. If you notice that Sonos coming through your receiver lags slightly behind your other Sonos zones, click here and we'll adjust the rest of the system to match that delay. If you haven't heard a problem, then your receiver is fine and you don't need to do anything more. Enjoy!"

Hopefully we can all agree that even the world's most meddlesome and intellectually challenged end user would have no inclination -- in the event he/she ever even got to the equalization screen, to click through both those screens and intentionally foul up his system.

Again, I agree that any changes to the features and interface should be carefully considered, but everything in this approach can be solved with a tiny one-time change to the Sonos software, instead of pushing thousands of dollars of unnecessary costs onto each Sonos customer affected, which in the end just means most of them are going to skip the zone or have a poorly performing system.

Hopefully we can all agree that even the world's most meddlesome and intellectually challenged end user would have no inclination -- ...

Don't under estimate the customer's imagination. An unbelievable number of consumers proudly boast that they don't read instructions -- they'll just keep clicking things till the box works the way that they think the box should work, or take it back if they can't click their way out. SONOS will factor the cost of future support costs into any potential feature addition.

... instead of pushing thousands of dollars of unnecessary costs onto each Sonos customer affected,...

In my opinion it is hundreds at most for the relay boxes and the delta between CONNECT and CONNECT:AMP is $150.00. If a fancy remote plus programming is used to cure the operational issues for the less savvy user, the total costs for the CONNECT scheme will probably be higher than the CONNECT:AMP/Relay scheme. These CONNECT operational issues will be present with or without the delay feature.

Aside from the exorbitant cost and complexity of the amp solution, remember that the amp solution also leaves us with only 2 or 4 speakers, no center channel, no surround field where the "xxx ms" solution gives far superior sound and takes advantage of the full array of speakers in the room. Is that a concern for you?

Don't under estimate the customer's imagination. An unbelievable number of consumers proudly boast that they don't read instructions -- they'll just keep clicking things till the box works the way that they think the box should work, or take it back if they can't click their way out. SONOS will factor the cost of future support costs into any potential feature addition.

So you're still saying that in spite of the description I've laid out you think people will go in and intentionally change something called "the receiver in this room delays the sound relative to other Sonos zones". OK, I'll leave that one for others to decide. I'm relieved to say that every one of my customers is smart enough not to do that, so lucky me. ;-)

In my opinion it is hundreds at most for the relay boxes and the delta between CONNECT and CONNECT:AMP is $150.00. If a fancy remote plus programming is used to cure the operational issues for the less savvy user, the total costs for the CONNECT scheme will probably be higher than the CONNECT:AMP/Relay scheme. These CONNECT operational issues will be present with or without the delay feature.

Hundreds for the equipment perhaps but I'm assuming you don't expect me to disassemble their home theatre and splice into all their speakers for free, right? 😉 But even if it's "only" $800, that's an $800 complex solution with inferior 2-channel audio versus my free solution with full depth surround. Why pay more for less? The "fancy remote" is not being used to cure operational issues. It's an excellent product in its own right. As I've said before in this thread, I don't tend to push the Connect because of this flaw. It represents less than 5% of our Sonos unit sales. Yet I still sell a Harmony remote with nearly every receiver becasue it's a great product and most people don't want to have 5 remotes on their coffee table or home theatre seat. I brought it up to address your houseguest example but it's in no way an incremental cost of the FREE "xxx ms" solution.

I can't help but feel like there's some other concern you have that's driving this because I've read enough of your posts here to know how knowledgeable you are about this stuff and yet for some reason the huge chasm I see in the appeal between the two solutions seems to be completely reversed for you. Perhaps we're both just a bit dug in, and we can just leave it to others to evaluate which solution works better for them. The plethora of +1's the thread has gotten over the years at least reassures me that I'm not the only one that likes the delay approach. Now that Sonos has implemented this delay (albeit in reverse) for the Playbar, hopefully they'll give us that option in the Connect soon as well. When they do I've got a list of all my clients with nice home theatres and no music and I'll be buying a big lot of Connects to go back and revisit each one of them.

--Jason

FWIW over on ask.sonos.com this issue is marked as 'under consideration'.

Having been forced to sell two nice DAC equipped units (one HK CD player, one dedicated) due to the missing lines of code (I'm a programmer, yes) I feel the need to chip in my

I did research (DIY and commercial) analog delays but couldn't see Sonos not implementing this down the line.. it's been 6-7 years.

Our setup is only 2 zones but we have them on radio in party mode 50-75% and I guess I'm not alone in frequently using the feature "group zones" in this system..

IMHO the Sonos menu system are full of choices and settings "normal users" (read; non technical that just likes music) could get wrong; "Line-Out Level",
"Local Music Servers" etc. but most people tend to stay away from changing stuff they don't understand or seem to need. That argument is null in my book.

The plethora of +1's the thread has gotten over the years at least reassures me that I'm not the only one that likes the delay approach. Now that Sonos has implemented this delay (albeit in reverse) for the Playbar, hopefully they'll give us that option in the Connect soon as well.

It won't bring my fine sounding DACs back but at least I can stop telling friends NOT to buy a Sonos system if they have an AVR and thinking about more than one zone... and most have both of those things :/

Sorry if I come across a bit sour, but this thread is soon 8 years old and now having some thread of hope for this simple addition being bombarded with non-arguments and convoluted objections makes me.. sour.

+ 1 on that great idea.

"Go into "Room Settings", tap on the Equalization panel and then pull the "This zone delays" slider to the right until everything sounds good.

Perfect way to match a slowed-down A/V receiver.

The implementation would require some memory (less than a Gig of ram) and a bit of processing in the Sonos equipment to buffer/delay the streaming signal.

New CONNECT/bridge components would probably need to be developped for that requirement.

+ 1 on that great idea.


Thanks!

Perfect way to match a slowed-down A/V receiver.

The implementation would require some memory (less than a Gig of ram) and a bit of processing in the Sonos equipment to buffer/delay the streaming signal.

New CONNECT/bridge components would probably need to be developped for that requirement.

I'm no engineer (but I play one on TV!) but I can't imagine that there's not the capability in the existing players to do this. I'd assume it's a non-starter if the current players are not capable of it. I don't think an enhancement is likely if it doesn't work on the installed base of millions of players.

That said, everything that's reaching the players is digital and is being converted at the player. The highest bandwidth content straming to a SONOS player is probably a FLAC file at about 5 MB per minute or about 85 kilobytes per second. Since the mot aggressive processing inside a receiver *still* only seems to slow things down by a fraction of a second, we should never be talking about more than a couple hundred kilobytes of buffered content. And that's with the combination of worst case delay and worst case file size.

Now that I think about it, I was listening to Spotify the other day and unplugged the Sonos bridge to move it. To my amazement the music continued for (I believe) a good 10~15 seconds even when the Bridge was down, so it would seem that the capacity to buffer is already more than adequate (my apologies if I've bungled any of the mechanics of this).

--Jason

My feeling is the players are probably capable of doing this, but there's probably quite a bit of complexity to deal with which makes it a major undertaking.

For instance, there are likely to be cases where the customer has multiple receivers, all which require a slightly different delay. In this case the system will need to implement a delay which at least covers the biggest delay in the system. It will have to delay all Sonos devices (including any Connect:AMP, Play:3, Play:5) by this delay, with Connect devices being delayed individually to suit their local requirements (nominally the system delay minus their local delay setting).

On top of this, the GUI needs to make it easy to set individual settings per Connect.

The extreme case is the customer has 32 zones of Connect devices with each connected to receivers with slightly different delays. This is, of course, a highly improbable case, but it is one that they would probably have to engineer to support on the basis that any real word scenarios will then easily be accommodated.

None of this is impossible, but there are some complexities involved which will require significant resources to develop and test.

Sonos has a finite resource for software development and testing and has to use it wisely. Clearly at the moment this particular feature hasn't yet been seen as high enough priority compared to other developments.

Cheers,

Keith

For instance, there are likely to be cases where the customer has multiple receivers, all which require a slightly different delay. In this case the system will need to implement a delay which at least covers the biggest delay in the system. It will have to delay all Sonos devices (including any Connect:AMP, Play:3, Play:5) by this delay, with Connect devices being delayed individually to suit their local requirements (nominally the system delay minus their local delay setting).

The first time I commented in this thread (oh, lo these many years) I was thinking of the same sityation:

I especially liked the suggestion above to allow each zone to have its own configurable "I delay by xx ms" setting. This is far better than having to manually adjust each other zone to add a delay.

It also takes care of a system with TWO zones with surround sound receivers. For example, if the Theatre adds 200 ms and the living room adds 100 ms, then when both zones are included in the party Sonos can delay the living room by 100 ms and all other zones in the house by 200 ms, but if the Theatre is not in the party then everything EXCEPT the living room gets a 100 ms delay.

And obviously 2 is an arbitrary number of zones. It could just as easily be 3, 4 or (in a ridiculous case) 32. The math couldn't be simpler. Every zone has a piece of metadata called LocalDelay. Then every zone in the Sonos buffers by [(Max(LocalDelay) - (LocalDelay)] milliseconds.

The extreme case is the customer has 32 zones of Connect devices with each connected to receivers with slightly different delays. This is, of course, a highly improbable case, but it is one that they would probably have to engineer to support on the basis that any real word scenarios will then easily be accommodated.

I still don't see think that makes [(Max(LocalDelay) - (LocalDelay)] especially complex, but I suspect we can all agree that such a hypothetical goes well beyond improbable. 🙂 So let Sonos look through their data and see what's the largest number of Connects that's ever been in a group before (remember, this only matters in a group), then double it and make that the limit to the number of distinct Connect delays on an existing system. Maybe it's 5, maybe it's 10. The point is nobody's ever going to reach it and if someone buys 32 connects just for the privilege of complaining they can pick from among the existing 5 or 10 delays the one that most closely matches their 11th zone.

Depending on how broad the range of delays is, and how narrow a delay a skilled listener can still here (is it 1 millisecond? 10? 100?) Sonos could choose to implement this with a dropdown instead of a slider. i.e. "This zone delays by xx milliseconds" and drop down to choose from 50, 100, 150, 200, 250, 300, 350, 400, etc etc etc.

I think you've missed my point.

Whilst it appears to be possible to implement and, the maths isn't hard, the low-level code to manage buffers and retain relative sync in real-time across multiple zones whilst implemented that math is probably a significant thing to implement, bearing in mind that most other vendors have struggled to get basic sync working reliably.

And, more importantly, it will involve many man months of development, debugging, and testing resource. That has to come from somewhere.

In well-managed development teams, this resource comes from one place only: being one of the most important development projects on the list.

Clearly, so far, this feature hasn't made that shortlist.

Cheers,

Keith