[SOLVED] Multiroom reciever drops out after a couple of minutes

[Zeable]

What kind of network?

The multiroom feature depends on consistent, high throughput, low latency network where the receivers are all within a millisecond or so of each other in terms of receiving packets from the sender.

All three devices are wireless through the Netgear RAX120 using the 2.4ghz channel. It is connected to a Cisco 3850 switch through two LACP bonded interfaces. Pings between these devices are all sub 1ms. Wireless signal is -59dBm or better. All other wireless devices on the network are going through different APs that are on different channels than the AP used for the multiroom setup.

[Tim Curtis]

Assuming the network is not contributing to the issue I'd try swapping to see if you can isolate the issue.

Swap in a different Pi as the receiver, a 3B+ for example
Swap to the 5GHz band

[Zeable]

Assuming the network is not contributing to the issue I'd try swapping to see if you can isolate the issue.

Swap in a different Pi as the receiver, a 3B+ for example
Swap to the 5GHz band

Will work on moving IPs and WiFi bands but wanted to correct my statement that all are sub 1ms. I did go back and retest and obviously not sub 1ms so wanted to share more accurate information.

Sender to receiver 1
50 packets transmitted, 50 received, 0% packet loss, time 428ms
rtt min/avg/max/mdev = 2.395/14.945/86.341/19.269 ms, pipe 9, ipg/ewma 8.741/30.349 ms

Sender to receiver 2
50 packets transmitted, 50 received, 0% packet loss, time 314ms
rtt min/avg/max/mdev = 2.081/7.073/37.599/7.105 ms, pipe 3, ipg/ewma 6.415/13.651 ms

Switch to sender
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/5/40 ms

Switch to receiver 1
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/5/54 ms

Switch to receiver 2
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/5/22 ms

[Tim Curtis]

Assuming the network is not contributing to the issue I'd try swapping to see if you can isolate the issue.

Swap in a different Pi as the receiver, a 3B+ for example
Swap to the 5GHz band

Will work on moving IPs and WiFi bands but wanted to correct my statement that all are sub 1ms. I did go back and retest and obviously not sub 1ms so wanted to share more accurate information.

Sender to receiver 1
50 packets transmitted, 50 received, 0% packet loss, time 428ms
rtt min/avg/max/mdev = 2.395/14.945/86.341/19.269 ms, pipe 9, ipg/ewma 8.741/30.349 ms

Sender to receiver 2
50 packets transmitted, 50 received, 0% packet loss, time 314ms
rtt min/avg/max/mdev = 2.081/7.073/37.599/7.105 ms, pipe 3, ipg/ewma 6.415/13.651 ms

Switch to sender
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/5/40 ms

Switch to receiver 1
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/5/54 ms

Switch to receiver 2
Success rate is 100 percent (100/100), round-trip min/avg/max = 2/5/22 ms

The sender to receiver ping stats show high avg rtt and really high standard deviation (mdev) which means there is a lot of variability in rtt. I'm guessing the Opus CODEC on the receivers can't cope with this and eventually just goes to white noise.

What I see on my network for example is avg rtt < 4.5ms and mdev < 1.5ms. It's a single Router with Sender connected via Ethernet and Receivers on 5GHz wireless.

[Zeable]

OK, I have set up a D-Link DAP-2695 AP in same room as the multiroom. I am able to get the Raspberry PI 4 and 5 to connect to the 5ghz band but the PI 3 will only connect to the 2.4ghz. The 5Ghz channel is clear, aka the only AP using this channel I can scan for is my AP. At this point I don't see how I could possibly get the WiFi any cleaner than this.

That being said. While the response times did improve, this did not help the issue at all. BTW, Receiver 1 is the PI 3 and Receiver 2 is the Pi 4.

Sender to receiver 1
50 packets transmitted, 50 received, 0% packet loss, time 298ms
rtt min/avg/max/mdev = 1.873/5.312/18.540/4.127 ms, pipe 2, ipg/ewma 6.072/5.037 ms

Sender to receiver 2
50 packets transmitted, 50 received, 0% packet loss, time 112ms
rtt min/avg/max/mdev = 1.294/1.777/3.491/0.478 ms, ipg/ewma 2.290/1.741 ms

[Tim Curtis]

It's not obvious to me what might be happening.
Basically, someone will have to reproduce your issue and hopefully provide some insight into what might be going on.

[abrakadabra2k]

@Zeable  does the journal (journalctl -S "today") give you anything helpful? I have this issue every once in a while due to a wifi dongle driver, leading to a short disconnect and falling back to 2.4GHz network.

Looks like this:

Oct 11 12:08:11 KitchenMoode kernel: rtw_8822bu 1-1.2:1.0: failed to get tx report from firmware
Oct 11 12:08:12 KitchenMoode wpa_supplicant[445]: wlan0: WPA: Group rekeying completed with *removed* [GTK=CCMP]
Oct 11 12:08:12 KitchenMoode kernel: rtw_8822bu 1-1.2:1.0: failed to get tx report from firmware
Oct 11 12:08:13 KitchenMoode wpa_supplicant[445]: wlan0: WPA: Group rekeying completed with *removed* [GTK=CCMP]
Oct 11 12:08:13 KitchenMoode kernel: rtw_8822bu 1-1.2:1.0: failed to get tx report from firmware
Oct 11 12:08:14 KitchenMoode wpa_supplicant[445]: wlan0: WPA: Group rekeying completed with *removed*[GTK=CCMP]
Oct 11 12:08:14 KitchenMoode kernel: rtw_8822bu 1-1.2:1.0: failed to get tx report from firmware
Oct 11 12:08:15 KitchenMoode kernel: wlan0: deauthenticated from *removed* (Reason: 16=GROUP_KEY_HANDSHAKE_TIMEOUT)
Oct 11 12:08:15 KitchenMoode wpa_supplicant[445]: wlan0: CTRL-EVENT-DISCONNECTED bssid=*removed* reason=16
Oct 11 12:08:15 KitchenMoode NetworkManager[443]: <info>  [1728641295.2359] device (wlan0): supplicant interface state: completed -> disconnected
Oct 11 12:08:16 KitchenMoode NetworkManager[443]: <info>  [1728641296.2055] device (wlan0): supplicant interface state: disconnected -> scanning
Oct 11 12:08:19 KitchenMoode wpa_supplicant[445]: wlan0: SME: Trying to authenticate with *removed*(SSID='removed' freq=2437 MHz)

[Zeable]

OK, with a little effort, and repurposing one of my AP's, I have it working without any issues. Basically, I set up a spare AP as a bridging repeater to provide wired ethernet. I now have the sender and receiver 1 connecting to the AP using copper and receiver 2 is still wireless. I expected that the sender and receiver 1 going ethernet would solve for receiver 1 but having receiver 2 now also behaving is not making sense to me. Being multicast and having one receiver or the other having the issue, I would have expected the 2nd receiver still having the issue. Since both are now behaving, I am calling this a win for now and will re-address this later when I have more time. I think the addition of the bridging repeater should not be necessary, but it is working for the time being.

Tim Curtis - Thank you for all your patience and wisdom in trying to assist.

abrakadabra2k - I am using the built in Wi-Fi on all 3 Raspberry PI's. I did run journalctl to see if I could see something stand out when the issue was happening, but I didn't see anything obvious.