The point I am raising is not about my ability to use or not use FMOD Studio myself.
Rather, as a developer, I’m raising my concern about a bug/shortcoming in a library my work depends on - FMOD, and its associated tool FMOD Studio.
If ASIO does not work for me, it will not work also for users of the software I ship that builds on FMOD.
And to any user of a software application, ASIO support, does not equal being able to use only the few devices that can do an 1024 buffer size. It means it will work with ‘any’ buffer size setting of any audio interface’s ASIO driver.
Audio interfaces provide ASIO drivers for very important reasons. They unlock access to crucial features for those devices, most importantly very low latency. Only being able to use Asio4All as opposed to native ASIO drivers, means any user loses the ability to access those very features, and is tantamount to not really supporting ASIO at all.
What I was hoping to hear in this conversation, is something along the lines of:
“Thank you for the bug report, we have filed it into our backlog”. And: “ASIO support is of importance to us, and we will include the fix to this bug in the next sprint”, or: “Unfortunately for us, ASIO support is not a priority, so we cannot commit to when we may be addressing this bug.”
You get my point. Speaking for the company I work for, as developers and users of FMOD, we want to know if this will be fixed, and if so when that is likely, as it is of great importance to us whether in the end it does work. It is in our case a feature that decides whether we will be using FMOD at all.