A better API for querying device capabilities

[mitchmindtree]

CPAL's current approach to querying capabilities is the Device::supported_formats method, which aims to enumerate all possible formats supported by the device. Providing an exhaustive list of formats in this manner is not very scalable, especially as we anticipate adding support for alternate sample formats, audio data layouts (#367) and buffer sizes in the future.

#203 proposes a slimmer API that allows querying individual formats, though this is equally unscalable for users wishing to determine the full set of capabilities of a device.

I wonder if we can look to Vulkan's device capabilities API for inspiration here? Edit: I guess Vulkan has the advantage of co-ordinating with driver implementers on a standard for this, whereas we are restricted to working with what host's currently provide access to.

A useful first step might be to consolidate all our existing knowledge of how capabilities are exposed by each Host so that we can get a clearer idea of what we have to work with. E.g. are the same sample rates supported for all sample formats across all hosts? Are supported sample rates always described in continuous ranges? Or do some hosts provide supported sample rates only as a set of discrete integers?

[msiglreith]

For audir I tried to follow Vulkan/OpenXR as far as possible with naming and everything.
API wise I ended up with sth like this: https://github.com/norse-rs/audir/blob/master/src/api.rs#L129-L154 (still missing quite a bit of stuff). Formats would be a per physical device query based approach.

Instance matches Host in cpal
PhysicalDevice/Device matches Device in cpal, but splits into physical and logical part

[sniperrifle2004]

I was going to put some suggestions forward based on the experience with alsas implementation, but I think #203 possibly combined with a list of common formats is the better approach and don't think this should be pursued at all. I created a gist about the problems with trying to enumerate the device capabilities (in alsa): Suffice it to say it's a mare's nest. To claim that the formats returned currently are supported (Which I think means they work) is just not true. Some might be, most might be, all might be. No guarantees. It will also often not cover all capabilities. That's less problematic than it sounds, but with the lack of a query API there is no other way to access those. You could improve that, but it would have to become much more complicated probably involving actual refining instead of just testing. Essentially you do something like a dfs over potential configurations. It's worse than it sounds. If you read my gist you will get an inkling as to why that is.

The closest alternative I could come up with was folding relevant hardware parameters into SupportedStreamConfigRange like the rate range is now. That gives some bounds to potential formats (That's useful), but the full range likely isn't supported. Still no guarantees, but much cheaper to deliver. Of course the SupportedStreamConfigRange of plug would still include 4GHz audio in any format imaginable, so lets say taking the maximum rate from SupportedStreamConfigRange would be unwise (#422. There is also a bounds error there, but the essence is the same). The plug plugin starts making sense when you give it a rate, but that's of no use when enumerating capabilities.