You are correct. I was thinking of the OSX driver which accepts up to 32bit int audio. Our Windows driver is older and is currently locked into 16bit. All we would have to do is provide 16, 24 amd 32bit float->fixed functions in the driver and we would support the higher bit rates. However, there are some legacy concerns with this driver and, according to Microsoft’s driver team “is not supposed to work at all”. We are investigating alternatives to the virtual audio driver method. But virtual audio drivers offer the most flexibility to the average user. It’s a tricky balance to maintain.
Have you tested this on a15? We are using a different method to get the data from C++ into .NET. It seems to be more efficient and disabling has a good effect on CPU usage (at least in my tests). The big difference between DPS and most .NET apps is the constant real-time communication between the .NET GUI and the lower level C++ dll that is doing the audio processing. .NET is like java in that it is interpreted instead of native. So whenever .NET has to talk native there is some overhead. We are working on optimizing this.