One possibly helpful set of tips:
You may have to get a bit creative since I learned by experiment that pipewire was truly up even though (alternative proof: ps aux | grep pipewire):
systemctl pipewire
or
systemctl pipewire.socket
did not show it as up but
systemctl --user pipewire
does/did.
Once you know enough to tug pipewire down (we’re going to disable pipewire for now since pulseaudo isn’t going away yet - the issue is that they are fighting over the same territory!):
systemctl --user disable pipewire
systemctl --user mask pipewire
systemctl --user stop pipewire
Sometimes, if you stop it first then disable it for instance, you still need another stop after disable/mask to ensure pipewire remains offline (restarts itself too quickly).
To verify that you have sound devices that are associated with anything other than either PulseAudio or Pipewire (my case there were often a mix of the two on the same PC):
fuser -v /dev/snd/*
Maybe even need to kill PulseAudio so that it can restart & grab anything it couldn’t grab earlier:
pulseaudio --kill
And if you see only one program capturing sound devices great but otherwise, dig some to find & disable the other program (I noticed wireplumber on one but that disappeared along with pipewire when I killed pipewire so is related).
See then if you can properly test your audio again. So long as only one set is actively attaching to resources they could both be installed so far as I can see.