Using BASS_WASAPI_CheckFormat to get the "highest bit resolution" would be much less overhead !
An update is in the BASSWASAPI package (see 1st post), in which the BASS_WASAPI_CheckFormat return value has been changed to a BASS_WASAPI_FORMAT value to indicate the maximum supported resolution. A new error code (BASS_ERROR_BUSY) has also been added for BASS_WASAPI_Init, to indicate that the device is busy, eg. in "exclusive" use by another process.
What might be even more thorough; is being able to get the "exact" match, perhaps with an (ExactMatch) boolean prameter defaulted to false. Where True says I need the exact resolution and False (default) returns the "highest" available.
Do you mean checking the support for specific resolutions? So long as BASS always uses the highest available resolution (as is currently the case), I'm not sure there is really any need for that.
This is for two reasons. One; is that the compiler/cpu accuracy of converting an integer into a range of +1.0 to -1.0 (32bit fp) isn't truly exact and two; to eliminate the overhead of 2 conversions (back and forth), and just pump the output to WASAPI.
32-bit floating-point can bit-perfectly maintain up to 24-bit integer data, so nothing will be lost in that conversion. If the source data isn't originally floating-point, it does mean some CPU overhead, but that is low. Note the lossy format decoders (eg. MP3/OGG/MPC/AAC) will generally produce floating-point data internally, so it is actually less overhead to keep them floating-point; I say "generally" as the Windows MP3 codec is an exception, as is WMA.
There are a few reasons for BASSWASAPI always using floating-point sample data, but primarilly it is to keep things simple; the user only has to use the BASS_SAMPLE_FLOAT flag when creating source streams regardless of the file format, and BASSWASAPI doesn't have to bother with converting between different integer resolutions (eg. if the user wants to play 24-bit data but the device only supports 16-bit). Another consideration is that BASS doesn't currently include 24-bit stream support, so the only way to play 24-bit files bit-perfectly is to use a floating-point stream anyway