FWIW, I am using Plasma and Pipewire on Wayland and don’t have any volume control issues. I guess it’s hard to tell the root cause of the reported problem, Could be hardware, could be software, could be configuration or a combination thereof.
Maybe @michaldybczak needs to do more in depth research to narrow the cause down to a single change in the system.
Btw, I recently had audio issues which were caused by bugs in the kernel, so it might be worth while trying an older LTS kernel.
Uhm…so…apparently it needed to boot a few times to get its juices flowing. Either that or installing another kernel (where the problem persisted) scared the others and they all work fine now. Anyways, false alarm.
Latest version of PipeWire 1:1.2.5-1 may have a bugfix for this issue, but has only been released to Unstable branch at the moment
Branch compare for Manjaro - pipewire
I was hit with the same bug and unfortunately I absolutely need virtualbox and its network connectivity for my daily work.
It is a well know bug that gets solved in version 7.1.2. Check bug #22164 in virtualbox bug tracker (apparently as I am a new forum user, the forum software doesn’t allow me to put links in my post yet, so I can’t post the direct link here).
I wonder, when will manjaro upgrade to virtualbox 7.1.2 ?
Anyway, time to learn how to downgrade a package in manjaro! 
Having held back packages is something I never wanted to do in an arch-based distro, but some times necessity drives actions (and mistakes)…
tsapi
VirtualBox 7.1.2 is in the Testing branch now…
I imagine it won’t be too far away, once testing is completed.
You didn’t need to downgrade! Look at r0nin’s response. Go to settings/Network and change "NAT " to “Bridged Adapter”.
Thank you very much for the suggestion.
I searched for solutions to the problem and I read in some places that even the “Bridhe Adapter” or “NAT Network” don’t solve the problem.
Moreover, I really need to have the VM SNATed with the IP of the host, because I have a really complex network and firewall setup with VPNs etc, which I hate to edit for temporary solutions, if I can avoid it.
If going back to VB 7.0.20 is doable and safe, it is definitely a better solution for my case.
I will let you know about what comes out of my “quest”. 
Thanks again for the input.
I might check and backport it to testing tomorrow.
I have found a work-around. For me if i change the network setting from NAT to Bridged adapter ( Settings > Network > Adapter > Attached to) and click ok THEN change the adapter back to NAT it works as designed.
This works until the host manjaro machine is rebooted or shut down. Hope this work-around can help anyone else as it helped me.
Im using KDE Plasma since 5.2 and i may just lucky with my 2 KDE system’s but i faced only minor problem’s with KDE.
While at the same time, i used custom Global Win7 KDE layouts that even working for 4 year’s now till today from Plasma 5.2 to Plasma 6.1.5.
No profile reset, no reinstall, no cache reset… my both KDE Desktop’s are just working and looking fancy at the same time (I’m only evade Widget’s).
Where is this hoop of fire, where everyone has to jump through? 
Another solution AT YOUR OWN RISK is to use the updated version where the problem is already fixed. In my opinion this package could be fasttracked to stable, but others might have a different opinion.
This solution should be generally avoided, but I don’t see big problems if you only have installed the main virtualbox package and no other virtualbox package. I have installed it myself without problems.
To install the updated version you have to download it from the unstable repo or install directly from there. For example:
sudo pacman -U https://repo.manjaro.org/repo/unstable/extra/x86_64/virtualbox-7.1.2-1-x86_64.pkg.tar.zst
And once more I reiterate that only do this if you understand the risk and accept that something can go wrong (but even it that case I suppose you can just downgrade the package to solve it).
Thank you for the suggestion. I think it’s a nice idea!
BTW - you are suggesting the package from the unstable branch? Why not the one from the testing?
I have actually 3 alternative solutions in my head:
)I am leaning towards the 3rd solution, at least in one of the PCs I am almost daily using (both have manjaro). I am a quite experienced user, used arch for years as daily driver with no issues whatsoever, the upgrade “packages” are smaller in testing I read (which I prefer), the general consensus is that the testing branch has very few (if any) problems and it is 2 steps away from arch stable anyway.
In the testing branch I may be able to give back something to the community.
Anyway, I will think it over a couple of drinks tonight and decide accordingly… 
I will let you know, guys.
Thanks for all input!
Only the 3rd option will be relatively safe and supported. The other 2 put you in unsupported state. It may or may not work, and may or may not break other things, now or in the future.
You are right, no one can deny it. Technically there is a risk, but it is a limited risk. The package in question is not a system library or utility. It’s an isolated software that has very limited impact in the rest of the system. It’s also already in use in Arch and in Unstable, so we know there is nothing special in it. That’s why I take the risk exceptionally to solve a problem with the version in stable. I don’t think it can go worse than already is.
Because both are version 7.1.2, but the one in unstable is a newer release, so I suppose that something has been fixed in the package (it’s just release version that has been updated, the application itself should be the same)
This is probably the better choice.
If VirtualBox 7.1.2 works as expected in Testing, then it will be a relatively easy path to switch back to Stable when this version reaches it.
For what it’s worth I have been running virtualbox 7.1.2 on the unstable branch and have not noticed any issues.
Just out of curiosity: if you do this, what happens when (and if) that version hits the stable branch?
As far as I know nothing will happen as you will already be on the latest version.
With that package nothing, the problem will be if it brings newer libraries that are shared with some other program, because that other package might break.
Thanks man, i had the same issue and your solution works just fine. 