Bridge two openwrt devices for Sonos surround

I want to be able to use Sonos connect:AMP together with Sonos Beam in surround sound mode.
For that, Sonos requires, both devices to either be wired directly, or connected to the same switch/router.
How can I achieve that using two openwrt devices, each connected to lan port of the respective Sonos unit?
Right now Beam is connected via an openwrt device configured as WIFI client + relayd.
It works, but then the amp has to wired into the same openwrt device with a cable.
If I put two openwrt in wifi client+relayd, I can access all devices fine (ping, app, etc), but there is no surround.
Perhaps WDS between the two openwrt devices? or dumb ap+ bridge?

Yeah, the relayd is doing some kind of proxy between the 2 networks and not everything works properly. WDS or some normal bridge (if possible) are preferred in such cases.

What kind of bridge would you suggest?
Is there any relevant tutorial on the topic?
The idea is to make the bridge between lan ports of the respective openwrt devices and the rest of the network transparent, to "fool" Sonos devices into believing, they are on the same switch.

It is just like @trendy already said, use WDS or full mesh 802.11s

But the best is to pull a cable and set the second router up as a dumb AP

1 Like

I do not have any specific suggestions to solve the problem (aside from following the guidance from Sonos), but I do think that surround isn't going to work if you try to 'fool' the system.

I suspect that the reason for the requirement is around latency. When using wifi, latency is much higher and also much more variable than it is when you're on a wired ethernet connection. As such, the surround performance would probably not be good/consistent or reliable when the devices are communicating with each other via wifi, especially if you have some extra stuff happening (i.e. relayd or wds). Keep in mind that a few extra milliseconds (or even 10s of ms) of additional latency isn't really an issue when music is distributed across multiple rooms... but with a surround system where the speakers are expected to have nominally nearly zero latency, any significant increase in latency and/or jitter caused by the variability of latency can cause significant degradation in the perceived quality of the surround experience.

If I'm right, your approach with trying to fool the system may fail because they can (and almost certainly do) easily measure the latency between speakers. If it is above some threshold, my guess is that the system will not enable surround (and they'll probably do this because they want to guarantee good performance).

I'm pretty sure you can make it work with just the connect:AMP hardwired and use the SonosNet to connect the AMP to the other speakers. I used to run that setup with a connect amp and 2 Play:5's. The SonosNet is basically a little wifi system that only works with sonos speakers.

Sonos systems buffer the audio when you start playing to deal with fairly large latencies, it works pretty well as long as your setup can deal with that initial buffering. That's why their soundbar systems use hdmi passthrough so that the video can stay synchronized even with that initial buffering.

Well, not with the Connect:AMP.
It doesn't support 5Ghz, so they force you into using a cable.
Anyway WDS appears to work well.
Sonos was successfully "fooled".
Which makes sense, since WDS is layer 2 bridge.

Frankly, I didn't notice any latency problems.
At least not with youtube 5.1 videos (haven't tried watching a 5.1 movie yet).
I don't think, the latency is a problem anyway.
I checked ping times and they are about the same as before, when the Sonos devices were wired using a cable between them (with wifi connecting them to the rest of the network, using relayd setup).

While that is true -- and certainly the case for the non-surround devices -- the problem comes in when the latency is highly variable which is not uncommon with wifi.

Even if they're using the HDMI pass-through to delay the video to accommodate the latency on the audio, there may be limits on the latency (average and standard deviation) that may be used dictate when surround is enabled/disabled.

Obviously, as we see from the OP's post above mine, we do see that it is working, so I can eat my words :rofl: ... but still, it wouldn't surprise me if there was a method they use to determine if the latency/jitter is too high (in this case, it's obviously okay)