The bit format has always been an issue. Originally we let the user choose which format was exposed via the ASIO interface through our ASIO Control Panel, but that just confused people. We eventually settled on exposing just 32-bit (best for transferring over PCI) and that seems to work just fine. Obviously for DSD support, the device would have to be put into a “DSD Mode” to let the app know that DSD is available since the driver can really only expose a single format at a time.
ASIO functions should just return ASE_NotPresent if the hardware has been unplugged.
I’m not seeing the value in knowing if something is PNP or not, since only PNP drivers can used on Windows Vista and up. I’m sure someone will want to argue that there is a way to load a non-PNP driver, but that is not standard practice at all and shouldn’t be considered for a professional shipping product.
Multi-client is an issue since that is not currently in the ASIO specification at all. At the moment the end-user has to know if a device supports multi-client, and how (pre-allocate channels for a single app or not). How would you propose expanding the ASIO specification for this?
How would you propose expanding the ASIO specification for this?
I would suggest a feature query function or message, with result data & plenty of room for additional information flags
BTW: About the multi-client. There drivers how support only on various application instances and on single instance no multi-client support. It’s even more complicated.
It would, f.ex, be possible to implement a custom ASIOFuture call without even changing the spec,
and publishing the selector code and parameter struct, suggestably in the device’s manual,
and then submit it to Steinberg for inclusion in the next SDK revision.
