Hi,
While tracking down why SoapyAudio wasn't working for me on Trixie (and it still isn't working), I discovered a change in RtAudio that flew under the radar as part of the problem.
See this comment on RtAudio "Version 6.0 breaks compatibility for no reason." https://github.com/thestk/rtaudio/issues/365#issuecomment-1245303883
https://github.com/thestk/rtaudio/blob/HEAD/RtAudio.cpp#L10003
https://github.com/thestk/rtaudio/blob/HEAD/RtAudio.cpp#L668

Unfortunately the data types and function prototypes have all remained the same, which is why this has flown under the radar and no indications of the breakage this would cause followed. This is not a theoretical issue; SoapyAudio isn't working on Trixie because it uses the prototypical loop to enumerate devices: https://github.com/pothosware/SoapyAudio/blob/HEAD/Registration.cpp#L38

I won't yet claim to have proven it, but I do believe SoapyAudio in both Trixie and unstable are probably totally broken. If I do 'SoapySDRUtil --find' with no non-audio SDR devices connected I see it prints this four times:
The English here is technically not right; the argument itself is found, of course (it's zero, one, two, or three each time), but no device with a matching deviceId number is found, due to the new numbering scheme.

Seeing as this problem is already in the Trixie release and this version of RtAudio required a SONAME bump and transition anyway in the first place, you could say the damage is done. There may not be much for the rtaudio maintainers to do, except check that other reverse dependencies are functioning correctly. I'm filing this bug against rtaudio because that's customary for packages that introduce breaking changes, but really SoapyAudio needs upstream attention here. I don't think this has yet been mentioned at https://github.com/pothosware/SoapyAudio/issues/21 https://github.com/pothosware/SoapyAudio/pull/24