Device ID offset between getDeviceInfo and RTWvIn

[kidproquo]

Hello,

This doesn't work:

auto deviceId = 0;
auto info = audio.getDeviceInfo(deviceId);
std::cout << "name: " << info.name << ", inputChannels: " << info.inputChannels << std::endl;
// Output: name: Focusrite: Scarlett 2i2 USB, inputChannels: 2
auto input = new RtWvIn(info.inputChannels, 44100, deviceId);
// Exception: RtApiCore::probeDeviceOpen: the device (1) does not support the requested channel count.

This works (add 1 to the deviceID when connecting):

auto deviceId = 0;
auto info = audio.getDeviceInfo(deviceId);
std::cout << "name: " << info.name << ", inputChannels: " << info.inputChannels << std::endl;
// Output: name: Focusrite: Scarlett 2i2 USB, inputChannels: 2
auto input = new RtWvIn(info.inputChannels, 44100, deviceId+1);
// OK, can get frames with input->tick

[garyscavone]

If the device number to RtWvIn is zero, then it calls getDefaultInputDevice(). So, the behavior you experienced is correct. However, you seem to also be using an instance of RtAudio, which does not treat device zero as a default.

[kidproquo]

I need to show a list of available devices and then connect to a selected device. This is why I am calling getDeviceInfo and then trying to connect to it with RtWvIn. The issue is that the device ID used with getDeviceInfo doesn't match the one used with RtWvIn - I guess this is by design and I just need to increment the device ID by 1 when using RtWvIn?

[garyscavone]

If you are going to use RtAudio directly for device enumeration, then maybe you should just use it for audio I/O too (instead of RtWvIn). RtWvIn isn't super robust. It is meant as an easy-to-use blocking option in STK but it adds latency and there can be overruns if the client can't keep up.

[kidproquo]

Makes sense. Thanks. Closing issue.