Linux, PipeWire: Nothing is visualized, despite everything else looking correct

[LRitzdorf]

Describe the bug

All the PipeWire tooling I've checked (patchbay, wpctl, pw-top) indicates that Cava is receiving audio. However, nothing is visualized, regardless of output method (tested with noncurses, ncurses, sdl).

In the terminal, control keys (e.g. to change colors) do work, so Cava itself isn't frozen or anything. Also, switching the input method to pulse does allow Cava to properly visualize, so this shouldn't be an issue with the output method either.

To Reproduce

Steps to reproduce the behavior:

1. Install cava, pipewire, pipewire-pulse, wireplumber.
2. Configure Cava to use the pipewire input method, and enable auto-sensitivity (for ease of testing).
3. Play audio and run Cava. Observe that visualizer bars remain at zero.

Expected behavior

Cava visualizes playing audio via the PipeWire input method..

Screenshots

The Cava node also properly goes into the idle (I) state when the player is paused, so I doubt this is an issue with PipeWire itself.

Desktop

• OS: Arch Linux (with pipewire and pipewire-pulse)
• Version: rolling (fully up-to-date)

Terminal emulator

Issue occurs regardless of output method (e.g. also with SDL), so the terminal isn't relevant

[pallaswept]

Hi @LRitzdorf :)

That does all seem correct. I notice audacious is using an unusually large quantum, I wonder if you've also tried this with some other player? Would you mind sharing the config you've used (for pipewire and pulse too) so I could try to reproduce this?

[LRitzdorf]

Sure, here's a test with Firefox, playing at a more reasonable quantum (still no Cava output).

I haven't done any particular special configuration — I'm running standard PipeWire from the Arch repos, the Pulse and JACK compatibility layers, Wireplumber as a session manager (no custom configs), pwvucontrol as a GUI configuration tool, and Helvum as a patchbay if I happen to need that level of control.

For what it's worth, I also have another machine, identically configured (as far as I can determine/remember), where Cava works as normal. I'd be happy to compare any relevant information between the two, but that'd require some guidance, since I'm not familiar with the details of PipeWire. (Audacious, with the same large quantum, also works with Cava on that machine.)

[pallaswept]

Thanks mate. That ginormous quantum was the only thing that stood out visually so I wanted to check it out, but it seems like it's not relevant or a problem, so thanks!

You gave a really useful bit of extra info in your first post, which is that it does switch to idle mode when you pause the music. That tells us it's for sure properly connected to the sound card it's monitoring, and the pipewire loops in cava are running, so it really helps narrow down what could be going wrong. It does kinda hint that cava is actually getting sent a silent signal. Since you've got helvum there, maybe you could try wiring it up like this (replace the wires you have now, with ones where the pink arrows are):

So that what you hear from the sound card, is a copy of what cava is hearing (rather than the normal thing where it's the other way around; what cava is hearing, is a copy of what the sound card is hearing). I suspect that you will hear nothing when cava is not dancing.

You might also like to try setting audacious as the source for cava with source=audacious in cava's config file. If you start audacious playing first and then start cava like that, it should have no problem connecting directly to the app. I suspect that you would see cava dancing whenever you're hearing music, this way.

Hopefully one of these tricks will give us a hint of where things go silent.

[LRitzdorf]

Appreciate the feedback! Unfortunately, neither test changes anything — even with the audio chain going from Audacious to Cava to my sound card, Cava displays nothing and I can hear music as normal. The entire chain goes idle when playback is paused, just like before, so PipeWire itself still seems to be happy.

Same thing for the second test, with the sound card and Cava both getting their inputs directly from Audacious. Music is audible as normal, but no response from Cava (even when I start it with playback already active).

I'm assuming this is a "no" given Cava's help output, but is there any chance we could enable some form of debug logging? (I'm happy to compile from source for this if needed, too.) It'd be interesting to check whether Cava thinks it's getting any data at all from PipeWire, given that PipeWire definitely believes it's sending data to Cava.

[pallaswept]

Huh, that's a strange one for sure. Like you say, pipewire sure is sending audio over there. Your hearing the music during that screenshot eliminates any routing or muting or volume issues to cava (by default, all that's not passed through, you get the same volume signal at the monitor ports as arrives at the inputs) or that the sound card monitor ports were a problem before. You mentioned the autosensitivity is on, so... I'm not sure. Since the sound gets there, it seems like it's more related to the actual visualisation, but you tried three different methods, so that doesn't seem likely, either...

I put a bit of code in the pipewire handler so I try to respond quickly in case I broke something, but it does seem to be alright, and I'm a bit out of my depth with the visualisation side of cava. I wonder if you have any idea here @karlstav ?

Also Happy New Year :)

[JesusXD88]

I have a similar issue, since a week or so, cava doesn't follow the default pipewire or pipewire-pulse default device. When I connect a bluetooth headset, cava still targets the on board laptop speakers.

[pallaswept]

I have a similar issue, since a week or so, cava doesn't follow the default pipewire or pipewire-pulse default device. When I connect a bluetooth headset, cava still targets the on board laptop speakers.

That sounds like a different problem. OP does not have a problem with the routing of pipewire/wireplumber, but only the visualisation within cava. It might be best if you file a separate issue.

[karlstav]

I'm afraid I got nothing. Could it be related to the active/always process settings?

[pallaswept]

Could it be related to the active/always process settings?

It seems to be working as expected - we can see that the nodes are running in the pw-top screenshot (the R in the left column). Even audio appears to be reaching cava without any problem (as demonstrated by changing the routing, to listen to the monitor of cava's input), but there's just no visualisation. I thought maybe the sensitivity might be the problem but OP said it is on auto. @LRitzdorf it might help if you could attach the config file here so we can check it out and try to replicate the fault on our end.

[LRitzdorf]

The config file is nothing fancy, and works fine on another machine. I'll attach it here anyway, though:

[general]
autosens = 1
sleep_timer = 1
[input]
method = pipewire
source = auto
[output]
method = sdl

Setting input.active = 1 doesn't change the display on Cava's side, but I can see that it and the sound card it's monitoring both stay "running" even when my music player is paused. That matches the pattern we've seen so far, of normal behavior from Pipewire's side of things.

[pallaswept]

I'm sorry, that's working fine here:

I'm using cava built from the master branch, which is slightly newer than your 0.10.6, but I don't think that would have any bearing on this.

[LRitzdorf]

Yeah, that doesn't surprise me, since the same config works fine on my other machine. (I did also build from master as part of my testing, and that broke in the same way as the Arch-packaged version.)

All I can think is that this is somehow machine-specific, but I have no idea where that'd be the case. Pipewire seems perfectly happy based on our earlier testing, and it can't be a graphics problem since the issue occurs regardless of output method. That's kind of why I was hoping we might be able to trace further via Cava itself, maybe even through basic "print debugging"?

Actually, input/pipewire.c doesn't look crazy complicated, so I may just play around with that on my end to see what Pipewire interactions are even happening at all.

[karlstav]

I will close this as it seems issue was local.

Feel free to re-open if needed.

[LRitzdorf]

Apologies for the delay; finally had time to dig into this a bit further. Results from poking around with adding printfs in input/pipewire.c:

• I can detect stream state changes via on_stream_state_changed(), which responds to play/pause events (states 2 and 3)
• on_process() is being called with new samples (when the stream is active, state 3)
• Those samples all seem to be zero(!!)

On that last point: my basic testing was just printing the contents of data->cava_audio->cava_in[i] for 0 <= i < n_samples, after the call to write_to_cava_input_buffers() on line 41. As I understand it, that last function call should be what populates that cava_in array, so it should be valid to examine after that point.

We checked this before, but I looked again, during the same Cava execution — Cava's monitor output does produce the correct audio if I drive my speakers from that.

Since it sounds like others can't easily reproduce this, is there anything else that would be helpful for me to report on, for further debugging?