Source: rtaudio Version: 6.0.0~ds-1~exp1 Severity: important Tags: upstream X-Debbugs-CC: [email protected] Control: affects -1 src:soapyaudio
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 > Worth mentioning that the new API is also breaking silently the functioning > of the device lookup. It's why I would recommend to change the type of > getDeviceInfo() type, or maybe change the signature of the method? > unsigned int devCnt = iHnd->getDeviceCount(); > for (unsigned int k = 0; k < devCnt; k++ ) > { > RtAudio::DeviceInfo info = iHnd->getDeviceInfo(k); > ///... > } This comment is terse, but what this person is referring to is that getDeviceInfo() used to take a numerical index. To enumerate all audio devices, one would call getDeviceInfo() in a loop with integers from zero up to the total number of devices. However, in version 6.0, the "device IDs" were changed to be magic cookies (in a similar vein to the UNIX gethostid() function) that do not start at zero. As a matter of fact they now start at 129. Take a gander: 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 > RtAudio endac; > int numDevices = endac.getDeviceCount(); > for (int i = 0; i < numDevices; i++) { > RtAudio::DeviceInfo info = endac.getDeviceInfo(i); > // ... > } 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: > RtApi::getDeviceInfo: deviceId argument not found. 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 -- System Information: Debian Release: 13.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.107+deb13-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
signature.asc
Description: This is a digitally signed message part
