Quote:
Weird. I found a bug fix in Jack itself from a year ago where apparently jack_deactivate when used with PipeWire didn't disconnect the ports. So that might be what you're seeing - but then I don't understand why it worked with the old code.
It can be that the new audio subsystem simply uses parts of the Jack standard that PipeWire breaks (i'm sure it does at least some things to get the device integration features), that can explain why it didn't happen in the old one. It's certainly PW's fault from here on.
I know the native jackd is to be recommended (and it's certainly doable on Pi where it's specialized use only for that), but on a general purpose system it's too difficult to set up, you get it
Quote:
I'll add an explicit removal just in case. [done, next build]
Indeed that is worth it, even at 48khz the devices seem to linger on, e.g. when switching to alsa (on both in and out) the jack sink was still showing.
Quote:
When you say "changing the sample rate", do you mean while Stereo Tool is running? I see that that fails here indeed. But the reason appears to be that the Jack instance is gone - I cannot even close it anymore, that returns an error.
Yeah i tried while running (what i usually did) and while closed. It seems that the reported sample rate by ST is 44100, the input seems disconnected, the output sems connected, but both are dead. Switching back to 48khz and they come back alive, just with 'Restart sound cards' option, with sample rate reported correctly 48000.
Again this is no biggie, the audio now works fine at 48, it's enough for now. I know you guys have more important stuff to do.
Quote:
I have everything loading dynamically now, so I'm going to merge the Jack and non-Jack builds now. No more _alsa and _jack binaries!
Nice, certainly useful and simpler.