artificiel
commented
5 months ago @4Evergreen4@EvergreenTheTree nice debugging. i presume the bug comes up in specific env conditions where ID's are not sequenced (just checked on a an arch linux install and they indeed go from 0 to getDeviceCount() - 1, so your problem does not show up here).
the OF binary-bundled version of rtaudio moved from 5.2 to 6.0 a year ago, and was bumped to 6.0.1 6 months ago, so the current OF version will support the (new?) ::getDeviceIds() approach.
can you organize your fix in a Pull Request?
if there are doubts about the transition support for ::getDeviceIds() it could wrapped in a check of RtAudio::getVersion() — but I'm not sure it's necessary as OF already uses 6.0.1; perhaps @danoli3 has an opinion on that.
danoli3
I recently tried compiling a project that uses openFrameworks (and also ofSoundStream) on Arch Linux and was running into crashes involving audio device selection. After a lot of time spent debugging I realized that it's because the RtAudio API around device listing and selection has changed in RtAudio 6.0.0 (released around a year ago), which is the version of the library in Arch Linux's repository (well, it's actually 6.0.1 but the result is the same).
The main difference is that you cannot rely on devices being between
0andRtAudio::getDeviceCount() - 1and instead must get the list of IDs fromRtAudio::getDeviceIds. The only functional change needed to support this is changing the for loop inofRtAudioSoundStream::getDeviceListtofor (unsigned int i: audioTemp.getDeviceIds()) { .... The application I was trying to compile also made the assumption about device IDs being contiguous from0togetDeviceCount() - 1, so presumably this would be a breaking change without wrapper functions to hide this new behavior. Maybe the solution is just to stick to a version of RtAudio < 6.0.0 but I at least wanted to document this issue here in case someone else came across it.