Bug 2180339

> As it worked in 0.3.66 this is a regression.

Still works for me.

> As showed in the screenshort, no data is pumped into the tunnel device.

Please attach said screenshot.

Also please explain what you are trying to do and how it fails.

> Also, the tunnel devices now have new identifiers ( send_* and receive_* )
> which means software relying on the old schema to link sinks need rewrites.

Yes, that's correct. This is also more correct and useful. Please keep in mind that correctly written tools should not depend on
port names, this can break at any time.

> In addition to the aboved bug, starting the desktopsession today, after the pw update under the day while the desktopsession was running continuously yesterday,
today qmmp and other apps did not want to play sound and stuck while trying to.

Please provide pw-dump output and output of pw-top when 'stuck'

> And .. still .. the default sink is not changeable, no matter what the various tools say they did. 

Works here. Please explain what you are trying to do so we can at least try to reproduce.

Created attachment 1952293 [details]
qmmp playing into tunnel with wirediagramm

short update: downgraded to 0.3.66, rebooting sender, rebooting the receiving side of the tunnel as well, and we are back in business.

I will now recheck if the upgrade still causes a bug, or if something else hang. The receiving side was already on 0.3.67

Update: updated back to 0.3.67 on sender side, restarted the desktopsession, restated the tunnelsetup and it's working.

Interesstingly the qpwgraph shows the same sink names as in 0.3.66 and no combined sink linkports ( playback + monitor in one device which helps a lot keeping the oversight, the new design. ). My guess, this will change if the wireplumber state dir gets deleted again, so it can restart from scratch. 

### notes

the none working tunnels have been loaded and unloaded several times on the sender side, the only constant was the receiving side setup. I have to assume, that there something frooze up.


### Problems left over:

default sink is still the false one and not changeable. 

new image attached : 

check image on the left bottom, it names the mainboard speakers as default, but new apps play on the hdmi device.
No matter what i change or which app i use to change it. Bug goes back to the time pw was installed.

Created attachment 1952305 [details]
wrong default sink used.

Created attachment 1952319 [details]
last procedure to set the default sink

Situation:

wireplumber state directory got deleted, pw got updated. We can assume a prestine default config. in the "wpctl status" is no default sink visible.

Now it gets set to the mainboard speakers ( 67 ) and "wpctl status" reflects this change.

Starting a new app, which has not been using audio since the wipe of the state dir, defaults to HDMI, instead of mb speakers.

it got also tried via :

pavucontrol
pactl set-default-sink alsa_output.pci-0000_0a_00.4.analog-stereo

with no change to the default sink behavior.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

For what's it worth now:

From tests i have some findings:

The crackling noise happens in WLAN mode of devices. 
Bandwidth is dropping periodically on those WLAN connections.

If a device is connected via LAN, no crackling noise happend yet, as with 1 Gb/s no bandwith problems occur.

As this happens on many different devices, it looks like a bug inside the wifi subsystem.