solved-Streaming over LAN hangs after switching from wi-fi to ethernet

Strangiato · 2022-10-04 15:19:54

Hi

I use Arch + Gnome and my system is fully updated.
I use NetworkManager and iwd backend to manage my wi-fi and pipewire-pulse to stream audio from my laptop to the speakers connected to my desktop computer over the local network.

Audio streaming stops working after the following steps:
1. connect to wi-fi network
2. stream audio over network
3. during the streaming, connect a network cable to the ethernet adapter

After the last step, my laptop disconnects from wi-fi and then the wired connection is stabilished (thanks to this dispatcher: https://wiki.archlinux.org/title/Networ … plugged_in
and the streaming hangs. Streaming works again after suspend/resume cycle.

Any ideas on how to make the streaming over network not hang after the last step?
Thanks for reading.

Last edited by Strangiato (2022-11-27 12:09:04)

ectospasm · 2022-10-07 00:22:19

Many applications misbehave when the network changes underneath them while they're functioning. If you restart or reload the application that is streaming audio over the network, does the stream resume after connecting the Ethernet cable? Depending on the software you're using you may be able to configure it to retry after the network changes.

You may need to reload pipewire-pulse if it's no other software that is streaming. I'm not that familiar with pipewire, you may need to configure it specifically to retry after the network changes. You may want to review the pipewire-pulse journal, if it's a systemd service.

Strangiato · 2022-10-07 13:17:58

ectospasm wrote:

Many applications misbehave when the network changes underneath them while they're functioning. If you restart or reload the application that is streaming audio over the network, does the stream resume after connecting the Ethernet cable? Depending on the software you're using you may be able to configure it to retry after the network changes.
You may need to reload pipewire-pulse if it's no other software that is streaming. I'm not that familiar with pipewire, you may need to configure it specifically to retry after the network changes. You may want to review the pipewire-pulse journal, if it's a systemd service.

I stream audio with Strawberry music player or Opera browser playing a video in youtube.
I have just done more tests, the result after the steps above is not always the same.
Sometimes the streaming even continues as expected, sometimes it hangs permanently until suspend/resume cycle, sometimes it hangs for a few seconds, then the laptop disconnects from the desktop computer, the remote audio output disappears from sound menu of Gnome and the sound is output from the laptop speakers.

When the streaming hangs for a few seconds and then the laptop disconnects from the desktop, journal log prints these messages:

out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:117985336 filled:11127136 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:117993528 filled:11135328 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118001728 filled:11143528 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118009928 filled:11151728 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118018120 filled:11159920 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118026320 filled:11168120 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118034512 filled:11176312 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118042712 filled:11184512 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118050904 filled:11192704 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118059104 filled:11200904 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118067304 filled:11209104 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118075496 filled:11217296 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118083696 filled:11225496 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118091888 filled:11233688 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118100088 filled:11241888 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118108280 filled:11250080 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118116480 filled:11258280 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118124680 filled:11266480 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118132872 filled:11274672 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118141072 filled:11282872 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118149264 filled:11291064 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118157464 filled:11299264 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118165664 filled:11307464 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118173856 filled:11315656 + size:8200 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118182056 filled:11323856 + size:8192 > max:4194304
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:51 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118190248 filled:11332048 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118198448 filled:11340248 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118206640 filled:11348440 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118214840 filled:11356640 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118223040 filled:11364840 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118231232 filled:11373032 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118239432 filled:11381232 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118247624 filled:11389424 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118255824 filled:11397624 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118264016 filled:11405816 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118272216 filled:11414016 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118280416 filled:11422216 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118288608 filled:11430408 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118296808 filled:11438608 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118305000 filled:11446800 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118313200 filled:11455000 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118321392 filled:11463192 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118329592 filled:11471392 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118337792 filled:11479592 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118345984 filled:11487784 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118354184 filled:11495984 + size:8192 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: spa.loop: 0x56414f5cbdf8: queue full 64, need 152
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: 0x56414f7f5de0: overrun write:118362376 filled:11504176 + size:8200 > max:4194304
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.pulse-tunnel: failed to connect: Timeout
out 06 23:21:52 arch-laptop pipewire-pulse[1116]: mod.zeroconf-discover: Can't load module: Erro no formato exec

I do not know if there is a bug with pipewire or something is misconfigured on my system.
Searching for the messages from journal log in the internet I do not find anything helpful.
Thanks for your help.

Last edited by Strangiato (2022-10-11 20:06:51)

ectospasm · 2022-10-08 13:42:37

It looks like pipewire-pulse is not behaving properly when you change the network. It's odd that when it doesn't recover, only a suspend/resume cycle fixes it. Are you able to restart pipewire-pulse instead? You may want to try the following commands (as root):

# systemctl stop pipewire-pulse
# ps -eaf | grep pipewire # to see if there are any pipewire-related processes running
# killall -9 <pipeware process names>  # repeat as necessary until the ps command above only returns your grep for pipewire
# systemctl start pipewire-pulse

I'm not familiar with pipewire, but the suspend/resume cycle is likely doing something similar to the above, but automatically. You may need to restart/reload audio clients as well.

Just curious, why do you often connect Ethernet instead of using WiFi all the time? Is your WiFi network slow (e.g., it's an older standard like 802.11n or earlier)? If you could obviate the need to change networks so often, that might be a sufficient workaround for this problem (not triggering it in the first place).

Strangiato · 2022-10-08 14:02:16

ectospasm wrote:

It looks like pipewire-pulse is not behaving properly when you change the network. It's odd that when it doesn't recover, only a suspend/resume cycle fixes it. Are you able to restart pipewire-pulse instead? You may want to try the following commands (as root):
# systemctl stop pipewire-pulse
# ps -eaf | grep pipewire # to see if there are any pipewire-related processes running
# killall -9 <pipeware process names>  # repeat as necessary until the ps command above only returns your grep for pipewire
# systemctl start pipewire-pulse
I'm not familiar with pipewire, but the suspend/resume cycle is likely doing something similar to the above, but automatically. You may need to restart/reload audio clients as well.
Just curious, why do you often connect Ethernet instead of using WiFi all the time? Is your WiFi network slow (e.g., it's an older standard like 802.11n or earlier)? If you could obviate the need to change networks so often, that might be a sufficient workaround for this problem (not triggering it in the first place).

I did not try to restart pipewire-pulse yet. Suspend/resume cycle is faster and easier to me.
I use an old laptop with slow 802.11n wi-fi. Sometimes I connect to ethernet to get faster downloads and copy to Samba shares, and also I'm testing streaming with ethernet because the streaming with wi-fi was stutering a lot. But I have found out that the stutering is not related to wi-fi. It also occurs with ethernet. This seems to be one more pipewire bug or a problem with the ethernet adapter of my desktop. I see many 'Rx errors' in its dmesg log.
Thanks for your help.

Last edited by Strangiato (2022-10-08 23:15:51)

ectospasm · 2022-10-10 01:40:02

Strangiato wrote:

I did not try to restart pipewire-pulse yet. Suspend/resume cycle is faster and easier to me.
I use an old laptop with slow 802.11n wi-fi. Sometimes I connect to ethernet to get faster downloads and copy to Samba shares, and also I'm testing streaming with ethernet because the streaming with wi-fi was stutering a lot. But I have found out that the stutering is not related to wi-fi. It also occurs with ethernet. This seems to be one more pipewire bug or a problem with the ethernet adapter of my desktop. I see many 'Rx errors' in its dmesg log.
Thanks for your help.

Having faulty hardware can definitely have an effect on this problem as well. So you get RX errors with your WiFi adapter, as well as your Ethernet NIC? Have you investigated upstream, like in your switches and router? Seems the network problem isn't in your hardware if both of them exhibit read errors. With faulty hardware you can't blame the software, and if your network is bad for whatever reason you'd need to fix that before addressing it in software. I guess you can start with the following on your laptop:

watch -n1 'ip -s link'

Pay special attention to the error counters. If you see those go up, for both your wireless and your Ethernet NICs, then the likelihood is a bad cable or network port on your router leading to your WiFi access points and Ethernet network. If your router has a self-contained WiFi antenna, then the problem could be within the router itself.

Where are you streaming from? If it's from the WAN/Internet, I'd rule out that link by streaming something on your LAN and see if the problem persists. Try to isolate where the problem is actually occurring. With any luck you just have a bad network cable that is causing this.

Strangiato · 2022-10-10 14:05:47

Sometimes I play a youtube video and stream its audio, sometimes I play a local audio file with Strawberry music player and stream the audio. On both cases the streaming stutters often regardless I use wi-fi or ethernet. Your command does not reveal any Rx error when my laptop is connected to wi-fi. But, when I
use the ethernet adapter, the number of Rx errors increases quickly even when I'm not sreaming audio over the network. Downloading a torrent or watching a video in youtube is enough to produce lots of Rx errors. I have 3 ethernet cables and all of them give the same result. I will test a usb wi-fi adapter with my desktop and see what happens while I stream audio when both laptop and desktop are connected
to wi-fi.

Edit:
Here are the statistics of the wi-fi adapter after streaming for 30 minutes:

4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 0c:d2:92:b5:4e:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast           
     462352546  920200      0      91       0       0 
    TX:  bytes packets errors dropped carrier collsns           
    1198845685 1093346      0       0       0       0

And the statistics of ethernet after streaming for 30 minutes:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 64:1c:67:62:de:27 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast           
     276879009  729490  66143     130       0     681 
    TX:  bytes packets errors dropped carrier collsns           
     841011149  780634      0       0       0       0

Edit2:

Auto-negatiation was off for my ethernet adapter. Here are the statistics afrer 30 minutes with auto-negotiation on:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 64:1c:67:62:de:27 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast           
     768223512  916480      0     122       0     696 
    TX:  bytes packets errors dropped carrier collsns           
     735501455  801023      0       0       0       0

Sometimes the streaming stutters due to dropped packets.

Last edited by Strangiato (2022-10-11 22:55:00)

Strangiato · 2022-10-14 18:09:20

I have no idea how to debug the modem/router provided by my ISP provider. The ethernet adapter of my desktop is crappy Realtek. Yesterday it lost connectivity while I was just browsing the internet, and I got more than 1200 Rx errors in a few hours. I need to replace this crap with an Intel pci/pci-e adapter.

If I can't suspend/resume for some reason, the stream can also be fixed by restarting pipewire-pulse, as you said:

systemctl --user restart pipewire pipewire-pulse

Despite my unstable network, I have reported my issues with streaming on pipewire bug tracker.

Here is the report about the main issue of this topic:
https://gitlab.freedesktop.org/pipewire … ssues/2747

The next version will have an option to adjust the latency, so the stuttering can be reduced/eliminated:
https://gitlab.freedesktop.org/pipewire … ssues/2755

ectospasm · 2022-10-14 22:18:21

Reporting bugs when you have defective hardware seems like the developers will just point to that and say they can't fix or work around that. You can use ethtool to see if you can adjust the parameters of your Realtek NIC, maybe increase its buffers, something that will workaround the faults. You may also want to increase the buffers in pipewire, if possible. I assume these are TCP streams, where retransmissions are expected and necessary? If they're real time streams (RTP, etc.), they're usually UDP and it doesn't make sense to retransmit in that case.

But yeah, the software streaming should be able to signal to the TCP stack that a packet arrived out of order, or appears to have been dropped, so it can be retransmitted before it dumps a frame to the audio device. A lot of that depends on the software streaming, whether that is capable.

Strangiato · 2022-10-20 01:54:53

ectospasm wrote:

Reporting bugs when you have defective hardware seems like the developers will just point to that and say they can't fix or work around that. You can use ethtool to see if you can adjust the parameters of your Realtek NIC, maybe increase its buffers, something that will workaround the faults. You may also want to increase the buffers in pipewire, if possible. I assume these are TCP streams, where retransmissions are expected and necessary? If they're real time streams (RTP, etc.), they're usually UDP and it doesn't make sense to retransmit in that case.
But yeah, the software streaming should be able to signal to the TCP stack that a packet arrived out of order, or appears to have been dropped, so it can be retransmitted before it dumps a frame to the audio device. A lot of that depends on the software streaming, whether that is capable.

I can't change the buffer of my NIC.

$ sudo ethtool -G enp4s0 rx 4096
netlink error: Operation not supported

I don't use RTP. I have configured the streaming according to instructions from Arch wiki.
https://wiki.archlinux.org/title/PipeWi … he_network

Apparently replacing the crappy Realtek NIC is the only way to solve RX errors on my desktop.

Edit:
dropwatch reports dropped packets on desktop computer while streaming:

$ dropwatch -l kas
Initializing kallsyms db
dropwatch> hw true
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
3 drops at location 0xffffffffbd4d7e31 [software]
1 drops at location 0xffffffffbd36a43a [software]
3 drops at location 0xffffffffbd4d7e31 [software]
1 drops at location 0xffffffffbd37252c [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd37252c [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd36a43a [software]
2 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd467c12 [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd45726a [software]
1 drops at location 0xffffffffbd36a43a [software]
1 drops at location 0xffffffffbd45726a [software]

Last edited by Strangiato (2022-10-20 02:36:10)

ectospasm · 2022-10-24 00:33:00

Sounds like it. In the face of hardware errors the rest of the software stack on top of the hardware can only do so much to workaround things.

I had a bad sound card on this laptop, that I could not reliably work around. Ultimately I sent the laptop in for warranty repair, and they replaced the mainboard. Hardware doesn't last forever, you're bound to need a replacement at some point.

If you're replacing NICs, I recommend Intel NICs. I use Intel NICs at home and at work, and I don't remember the last time I had a problem I could blame on the networking hardware.

Strangiato · 2022-10-25 13:55:40

ectospasm wrote:

Sounds like it. In the face of hardware errors the rest of the software stack on top of the hardware can only do so much to workaround things.
I had a bad sound card on this laptop, that I could not reliably work around. Ultimately I sent the laptop in for warranty repair, and they replaced the mainboard. Hardware doesn't last forever, you're bound to need a replacement at some point.
If you're replacing NICs, I recommend Intel NICs. I use Intel NICs at home and at work, and I don't remember the last time I had a problem I could blame on the networking hardware.

Ping from the machine with Realtek NIC to modem/router gives packet loss. Ping from my laptop connected to wi-fi (intel wi-fi adapter) also gives packet loss. The loss of some packets with wi-fi is unavoidable, no? However, ping from my laptop connected via cable (Qualcomm Atheros NIC) gives no packet loss. I will replace the Realtek NIC of my desktop with an Intel NIC. Obviously it is failing.

Thanks for your help again.

Last edited by Strangiato (2022-10-25 14:00:48)

ectospasm · 2022-10-30 16:01:38

Strangiato wrote:

Ping from the machine with Realtek NIC to modem/router gives packet loss. Ping from my laptop connected to wi-fi (intel wi-fi adapter) also gives packet loss. The loss of some packets with wi-fi is unavoidable, no? However, ping from my laptop connected via cable (Qualcomm Atheros NIC) gives no packet loss. I will replace the Realtek NIC of my desktop with an Intel NIC. Obviously it is failing.
Thanks for your help again.

Actually, Wi-Fi packet loss shouldn't happen, either, unless there are a lot of walls and distance separating your laptop from the nearest access point. I have a DIY router based on an Intel NUC with dual Gigabit Intel NICs (running Arch, I wrote a series of blog articles describing how I set it up), and I migrated to an Ubiquiti UniFi system when I was dissatisfied with my Atheros 802.11n WiFi NIC I put in the router. Granted, I've spent quite a bit on the UniFi hardware, but I've been much happer with it. Over the last couple of years, I've bought two 8-port UniFi switches, and two APs. The UniFi controller software is free (it's even in the AUR), and the web GUI management console is pretty nice (and I usualy HATE GUI management consoles).

But more to your question, WiFi shouldn't be losing packets, either. You may want to investigate your router, as its WiFI NIC(s) can be problematic as well.

EDIT: I ran a continuous ping from my laptop over WiFi, to my router, for 2.79 hours. Zero percent packet loss, and there are definitely walls and a floor between my laptop and either access point. That's over 10,000 ping requests, and none were lost.

Last edited by ectospasm (2022-10-31 01:17:41)

Strangiato · 2022-10-30 18:18:09

My laptop is near router and there is no wall between them.
After more tests, I noticed packet loss even when the laptop is connected to wired network.
But I'm not sure if the ping statistics below could indicate an issue with my modem/router.

Ping statistics after 24 min with laptop connected to Wi-Fi:

--- 192.168.0.1 ping statistics ---
1447 packets transmitted, 1446 received, 0.0691085% packet loss, time 1448064ms
rtt min/avg/max/mdev = 1.217/2.331/170.339/5.105 ms

Ping statistics after 52 min with laptop connected to wired network:

--- 192.168.0.1 ping statistics ---
3139 packets transmitted, 3133 received, 0.191144% packet loss, time 3152999ms
rtt min/avg/max/mdev = 0.628/1.072/18.853/1.331 ms

Maybe I need to replace both modem/router and desktop NIC.

Last edited by Strangiato (2022-10-30 18:21:34)

ectospasm · 2022-10-31 01:18:22

I ran a continuous ping from my laptop over WiFi, to my router, for 2.79 hours. Zero percent packet loss, and there are definitely walls and a floor between my laptop and either access point. That's over 10,000 ping requests, and none were lost.

Strangiato · 2022-10-31 02:18:11

ectospasm wrote:

I ran a continuous ping from my laptop over WiFi, to my router, for 2.79 hours. Zero percent packet loss, and there are definitely walls and a floor between my laptop and either access point. That's over 10,000 ping requests, and none were lost.

Interesting. Thanks for sharing your experience.
Despite a little packet loss, apparently my network is not so bad. Right now my laptop is connected to Wi-Fi,
I'm streaming audio with Roc - roc-git package from AUR - for test purposes and it works nicely. However, streaming with Pipewire currently is impossible. It stutters all the time.

Last edited by Strangiato (2022-10-31 02:25:28)

ectospasm · 2022-11-01 01:38:14

Strangiato wrote:

Interesting. Thanks for sharing your experience.
Despite a little packet loss, apparently my network is not so bad. Right now my laptop is connected to Wi-Fi,
I'm streaming audio with Roc - roc-git package from AUR - for test purposes and it works nicely. However, streaming with Pipewire currently is impossible. It stutters all the time.

I bet Roc has buffers in the application layer that workaround jittery and unstable networks. Do you notice any delay when you start streaming with Roc? My guess it takes a moment to buffer, but is fine once it fills the buffer. I bet it streams over TCP, and only sends a full frame to the audio device when the buffer is full. Then, if a packet arrives out of order or is dropped, the TCP layer handles this gracefully and the Roc buffer isn't affected too badly.

It is likely pipewire has no such buffer, and that's why it stutters over the enetwork. This is all conjecture, I don't know the implementation detials of either Roc or pipewire.

Strangiato · 2022-11-01 02:29:28

ectospasm wrote:

Strangiato wrote:
Interesting. Thanks for sharing your experience.
Despite a little packet loss, apparently my network is not so bad. Right now my laptop is connected to Wi-Fi,
I'm streaming audio with Roc - roc-git package from AUR - for test purposes and it works nicely. However, streaming with Pipewire currently is impossible. It stutters all the time.
I bet Roc has buffers in the application layer that workaround jittery and unstable networks. Do you notice any delay when you start streaming with Roc? My guess it takes a moment to buffer, but is fine once it fills the buffer. I bet it streams over TCP, and only sends a full frame to the audio device when the buffer is full. Then, if a packet arrives out of order or is dropped, the TCP layer handles this gracefully and the Roc buffer isn't affected too badly.
It is likely pipewire has no such buffer, and that's why it stutters over the enetwork. This is all conjecture, I don't know the implementation detials of either Roc or pipewire.

Yes, there is a delay when the streaming stars. And when I play a video in youtube, for example, audio and video are not synchronized.
Streaming with Roc also stutters sometimes, but it is ok when I stream only audio.

ectospasm · 2022-11-02 22:54:00

One thing I forgot to mention, if audio is OK with Roc but video is stuttering still, you might have a bandwidth problem. I assume you have a Gigabit Ethernet network (NICs, switches, etc.). I'd make sure your NICs aren't set to 100Mbit. You should be able to see that and modify it with ethtool, as mentioned previously.

Also, what 802.11 standard is your WiFi router? If it's not at least 802.11ac, you're probably hobbled by bandwidth there as well. The next previous standard that I'm aware of was 802.11n, which tops out at 30Mbit. You said your laptop is rather old, and it has an 802.11n WiFi NIC. Streaming video would likely be very painful, given you don't have a completely reliable network. Not really a whole lot of speed if you have multiple devices trying to stream.

Strangiato · 2022-11-03 16:49:36

Both Wi-Fi NIC and router are 802.11n. The ethernet adapter is 100 Mbps.
Unfortunately hardware is expensive in my country and I can't upgrade.
The stuttering occurs even if the internet is not in use while streaming.

ectospasm · 2022-11-05 12:34:55

Strangiato wrote:

Both Wi-Fi NIC and router are 802.11n. The ethernet adapter is 100 Mbps.
Unfortunately hardware is expensive in my country and I can't upgrade.
The stuttering occurs even if the internet is not in use while streaming.

Understood. It looks like you have two things going on, unreliable and slow network gear. You can see if you can increase the buffer size in Roc, but beyond that you'll probably have to live with the stuttering.

Strangiato · 2022-11-05 13:49:31

ectospasm wrote:

Strangiato wrote:
Both Wi-Fi NIC and router are 802.11n. The ethernet adapter is 100 Mbps.
Unfortunately hardware is expensive in my country and I can't upgrade.
The stuttering occurs even if the internet is not in use while streaming.
Understood. It looks like you have two things going on, unreliable and slow network gear. You can see if you can increase the buffer size in Roc, but beyond that you'll probably have to live with the stuttering.

Are you sure 802.11n and ethernet 100 Mbps are a problem in my case? System monitor reports that the upload speed is 280 KiB/s or less while streaming.

Last edited by Strangiato (2022-11-05 13:51:49)

ectospasm · 2022-11-05 14:20:46

Strangiato wrote:

Are you sure 802.11n and ethernet 100 Mbps are a problem in my case? System monitor reports that the upload speed is 280 KiB/s or less while streaming.

Remember, those upload/download speeds are measured in KiB/s, not Kbps. So, your theoretical maximum is 30Mbps with 802.11n, which is roughly 3.75MiB/s. Your practical maximum is likely much lower than that. Check your download bandwidth while streaming, if it approaches 2-3MiB/s, you're likely maxing out your connection. And remember these speed measurements are only estimates, they fluctuate with bursts of speed.

EDIT: You may want to install something like iperf or iperf3 to measure your speeds between your desktop and your laptop, rather than relying on a streaming application to measure bandwidth. Both of these are available in the community repository, so they're a pacman -S iperf{,3} away. Note that iperf3 is incompatible with iperf, so pick one or the other.

Last edited by ectospasm (2022-11-05 18:49:43)

Strangiato · 2022-11-05 19:49:13

Here is the speed measurement while streaming using Wi-Fi:

$ iperf3 -c 192.168.0.50 -f K
Connecting to host 192.168.0.50, port 5201
[  5] local 192.168.0.18 port 55036 connected to 192.168.0.50 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  5.68 MBytes  5818 KBytes/sec    0    279 KBytes       
[  5]   1.00-2.00   sec  5.41 MBytes  5536 KBytes/sec    0    345 KBytes       
[  5]   2.00-3.00   sec  4.41 MBytes  4518 KBytes/sec    0    362 KBytes       
[  5]   3.00-4.00   sec  4.47 MBytes  4581 KBytes/sec    0    362 KBytes       
[  5]   4.00-5.00   sec  5.41 MBytes  5536 KBytes/sec    0    380 KBytes       
[  5]   5.00-6.00   sec  4.97 MBytes  5090 KBytes/sec    0    404 KBytes       
[  5]   6.00-7.00   sec  5.10 MBytes  5218 KBytes/sec    0    404 KBytes       
[  5]   7.00-8.00   sec  5.10 MBytes  5218 KBytes/sec    0    404 KBytes       
[  5]   8.00-9.00   sec  4.10 MBytes  4200 KBytes/sec    0    404 KBytes       
[  5]   9.00-10.00  sec  3.36 MBytes  3435 KBytes/sec    0    404 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  48.0 MBytes  4915 KBytes/sec    0             sender
[  5]   0.00-10.04  sec  46.5 MBytes  4744 KBytes/sec                  receiver

iperf Done.

Edit:
Speed measurement with wired connection:

$ iperf3 -c 192.168.0.50 -f K
Connecting to host 192.168.0.50, port 5201
[  5] local 192.168.0.15 port 46392 connected to 192.168.0.50 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.5 MBytes  11781 KBytes/sec    0    109 KBytes       
[  5]   1.00-2.00   sec  11.2 MBytes  11454 KBytes/sec    0    109 KBytes       
[  5]   2.00-3.00   sec  10.9 MBytes  11199 KBytes/sec    0    116 KBytes       
[  5]   3.00-4.00   sec  11.2 MBytes  11454 KBytes/sec    0    116 KBytes       
[  5]   4.00-5.00   sec  10.9 MBytes  11199 KBytes/sec    0    116 KBytes       
[  5]   5.00-6.00   sec  11.2 MBytes  11454 KBytes/sec    0    116 KBytes       
[  5]   6.00-7.00   sec  10.9 MBytes  11200 KBytes/sec    0    116 KBytes       
[  5]   7.00-8.00   sec  11.2 MBytes  11454 KBytes/sec    0    116 KBytes       
[  5]   8.00-9.00   sec  10.9 MBytes  11199 KBytes/sec    0    116 KBytes       
[  5]   9.00-10.00  sec  10.9 MBytes  11199 KBytes/sec    0    116 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   111 MBytes  11359 KBytes/sec    0             sender
[  5]   0.00-10.00  sec   110 MBytes  11311 KBytes/sec                  receiver

iperf Done.

Last edited by Strangiato (2022-11-05 20:18:05)

ectospasm · 2022-11-05 23:58:42

So that's a little bit better than I expected, but not orders magnitude better. You always get more throughput with a wired connection with 100Mbps Ethernet over 30Mbps 802.11n. I'd run iperf3 for more than ten seconds, run it for an hour or more. You may want to play with your MTU, try smaller or larger and see what effect that has on iperf3. The Arch Wiki Networking Guide has some suggestions for tweaking the MTU and TX queue length. You can use iperf3 to test various settings, and see which works best for your network. I'm not sure if your switches can do jumbo frames, but it's something to try.

Arch Linux

#1 2022-10-04 15:19:54

solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#2 2022-10-07 00:22:19

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#3 2022-10-07 13:17:58

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#4 2022-10-08 13:42:37

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#5 2022-10-08 14:02:16

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#6 2022-10-10 01:40:02

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#7 2022-10-10 14:05:47

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#8 2022-10-14 18:09:20

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#9 2022-10-14 22:18:21

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#10 2022-10-20 01:54:53

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#11 2022-10-24 00:33:00

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#12 2022-10-25 13:55:40

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#13 2022-10-30 16:01:38

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#14 2022-10-30 18:18:09

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#15 2022-10-31 01:18:22

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#16 2022-10-31 02:18:11

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#17 2022-11-01 01:38:14

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#18 2022-11-01 02:29:28

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#19 2022-11-02 22:54:00

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#20 2022-11-03 16:49:36

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#21 2022-11-05 12:34:55

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#22 2022-11-05 13:49:31

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#23 2022-11-05 14:20:46

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#24 2022-11-05 19:49:13

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

#25 2022-11-05 23:58:42

Re: solved-Streaming over LAN hangs after switching from wi-fi to ethernet

Board footer