Change:
config = mkIf cfg.enable { assertions = [ { <del> assertion = cfg.pulse.enable -> !config.hardware.pulseaudio.enable; message = "PipeWire based PulseAudio server emulation replaces PulseAudio. This option requires `hardware.pulseaudio.enable` to be set to false"; </del> <ins> assertion = cfg.audio.enable -> !config.hardware.pulseaudio.enable; message = "Using PipeWire as the sound server conflicts with PulseAudio. This option requires `hardware.pulseaudio.enable` to be set to false"; </ins> } { assertion = cfg.jack.enable -> !config.services.jack.jackd.enable; message = "PipeWire based JACK emulation doesn't use the JACK service. This option requires `services.jack.jackd.enable` to be set to false"; } <ins> { # JACK intentionally not checked, as PW-on-JACK setups are a thing that some people may want assertion = (cfg.alsa.enable || cfg.pulse.enable) -> cfg.audio.enable; message = "Using PipeWire's ALSA/PulseAudio compatibility layers requires running PipeWire as the sound server. Set `services.pipewire.audio.enable` to true."; } </ins> ]; environment.systemPackages = [ cfg.package ]

Discussion:
After Wireplumber was enabled by default in , audio and video playback completely broke on my machine (NixOS-unstable, GNOME on X11, x86_64-linux). Preview thumbnails of videos did show, but clicking "play" on audio/video tracks does nothing. I've observed this directly in Firefox, Element Desktop, Freetube, Rhythmbox and Signal. Reverting by putting into my config resolves the issue. Steps to reproduce the behavior: Firefox to play a video since you authored the PR Please run and paste the result.
I've also verified that this isn't resolved by .
I am also experiencing issues with video playback, I am glad i found this issue. seems to have fixed it
Known regression with pipewire 0.3.48 and wireplumber 0.4.8. Should be fixed by .
I've tried to apply the fix from with: but it didn't resolve the issue for me.
That is strange. What's the store hash of your wireplumber build after this?
With the nixpkgs revision , I get: I haven't applied any overlays that influence wireplumber. (Checked by directly building wireplumber from your Nixpkgs PR branch)
That hash does seem to match. I wonder if it's a different issue then... Can you also run ?
By the way, if you want to, we can continue this on Matrix (I'm there).
Honestly at this point I'd probably just report a bug upstream, or ask around in
Okay, thanks, I'll try that. Do you happen to know whether wireplumber has some sort of "verbose/debug log" build option which might make it easier to find the bug?
Try WIREPLUMBER_DEBUG=10
You should try zapping all config and cache. Especially if you use bluetooth (in which case the bluez cache).
I've been having this issue, too, on unstable. What I've noticed is that, on reboot or logout/login, playing a video works just fine the first time. But on the second and subsequent times, video won't play. A stil image from the video is displayed, but the video doesn't play at all. Here's what I see with : For me, running fixes this problem immediately. That is, videos suddenly start playing.
Is this with the patch or without?

I also wanted to note that I've reported the issue upstream now (), maybe a few more log dumps from other people with this issue will help the developers over there
there might be relevant details here
How are you enabling Pipewire? Something like the snippet below?
That's an interesting question. I didn't explicitly enable Pipewire anythere, my sound config is just: Basically, I have no idea of audio systems on Linux and I just assumed that it was some sort of backend for PulseAudio. On my system however, the Pipewire and Wireplumber services are there. Maybe that's some sort of bug in the NixOS audio submodules?
With , I've confirmed that something in my config indeed causes to be set to true, but are all false.
I've backtraced this and is set by , which is in turn enabled by default on Gnome (nixos/modules/services/x11/desktop-). It might be worth to open an issue for that.
This is really useful debugging information! Take my next paragraph with a grain of salt, since I am not a PipeWire expert. Some parts of PipeWire relate to screensharing (which is probably why enables it) and supposedly should work even without the ALSA/PulseAudio/Jack emulation, but sometimes there are bugs in the session managers; for example, was a bug in the old session manager with a similar outcome. I think that screensharing use cases are meant to work even for PulseAudio users (that is, without enabling PipeWire's PulseAudio "emulation" layer).
It seems that part of the problem is that had those extra knobs for turning various emulation layers on and off (such as and ), but those are no longer respected when using WirePlumber. This might lead to some weird conflicts for PulseAudio users (for example, if WirePlumber decides to start pipewire-pulse).
But does this mean that the WirePlumber switch broke audio for every GNOME user that does not use PipeWire? This seems like the default config!
Those knobs are for Pipewire itself, not pipewire-media-session. Wireplumber should still be functional in a mixed PW/Pulse setup, so it's probably worth reopening the upstream issue.
I'd ask someone else to open that issue though because my knowledge on this topic is close to zero, and I'll probably not be able to accurately describe the technical details here.

I've also tested this on my laptop, and it has the same issue, so that actually seems like a realistic possibility. I'm not really sure when it comes to user statistics, but from what I've seen, GNOME tends to be mostly used by less experienced users, while KDE and WMs like i3 are a lot more popular among advanced users, and the unstable repositories of an operating system are generally almost exclusively used by advanced users. So after considering the small user base of NixOS, it's really possible that there are just not that many GNOME/nixos-unstable users who are likely to encounter that bug.
Ideally yes, but there are two places in the NixOS module that look at : uses it to decide if the systemd service should be installed, and looks at it to create the file. Therefore, is given a hint that pipewire-pulse shouldn't be started, while upstream WirePlumber does not seem to have such an option. If I had to bet, I'd say WirePlumber does not currently support this use case.
pipewire-media-session doesn't start pipewire-pulse, systemd does. Wireplumber should detect the right setup automatically.
Yeah the file dates back to before the systemd service for pipewire-pulse existed. It is probably redundant nowadays.
I agree with what you two are saying, but I think I didn't express myself clearly, so I will try again; apologies if this is annoying. My point is that we have no indication that WirePlumber is designed to support mixed setups. The release notes for WirePlumber 0.4.0 say "It is a fundamental goal of this series to maintain compatibility with pipewire-media-session, making WirePlumber suitable for a desktop PulseAudio & JACK replacement setup, while supporting other setups as well (ex. automotive) by making use of its brand new Lua scripting engine, which allows making customizations easily." and it's unclear if they care about our use case (IMO it would be perfectly reasonable to not support PulseAudio). I'll ask upstream.
Pipewire and Pulseaudio are (should be) mutually exclusive. They both try to multiplex the underlying hardware, so if you're running both of them, that may or may not work depending on whether the physical sound hardware is capable of handling multiple streams. Some is, some isn't.

It's not as common to have that functionality as it used to be, since modern CPUs are more than capable of handling it in software. How it should work is that: If is set, that brings up the default audio manager. Whatever that is. Pipewire would be a good choice. If is also set, that enables pulseaudio and disables pipewire. If both pulseaudio and pipewire are explicitly enabled, that should hit an assert. There are very few cases in which enabling both makes any sense. Pipewire has a pulseaudio compat layer; this is not the same thing as running pulseaudio itself. But I haven't checked the actual behaviour of nixos, so I have no idea what's happening. Try ; this should tell us what is running on your system.
That is not true. Pipewire can be used for video and audio, and running Pulse for audio and Pipewire for video is a supported configuration.
Is that in fact how we're using it? Or is it opening the sound devices regardless? ...I should just check. Will report back later.
With Pulseaudio enabled (by ), Pipewire started when I opened a video on youtube, and no sooner — there was, however, no sound. Chrome connected to pulseaudio regardless. Pavucontrol reported no sound output devices available; only sound input was possible. A bit of searching in /proc indicated that pipewire was holding the audio devices open, and my sound card indeed only supports one stream at a time... but I'm unable to confirm that this is the issue. Regardless, I was only able to make sound work by either completely disabling pipewire, or completely disabling pulseaudio. I concur the Pipewire should be usable without making it grab the sound devices. However, how does one tell it to avoid that?
Hmm without looking deeply into it, I'm guessing the problem is that wireplumber and we don't have any way of configuring that via nix yet. Can you try if it works with pipewire-media-session if you disable all the audio stuff? This should cause alsa-monitor to never get loaded in pipewire:
That works flawlessly, as mentioned in my initial message in this thread.
Right, so this is the point where we have to make wireplumber configurable via nix.

There has been towards that but the lua system maps rather badly to nix so nothing in nixpkgs yet. As an interim solution I think we should add an assert that tells people to manually switch back to media-session if they have both wireplumber and pulseaudio enabled?
Fixed problem for me
I must say that this problem has been driving me crazy and you guys just prevented hours of debugging. I will try your fix and report any problems.
OK, I think we need to add an assertion here. I'll do it tomorrow unless someone snipes me.
So, while switching to Pipewire is nice, I really don't think that justifies breaking people's mixed PW/Pulse setups. Please test the fix in if you're affected (and make sure you disable Pipewire beforehand).
where do you put this?
Please don't bump one-year-old threads. File a new issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there: