Investigate why WASAPI Shared requires a matching sample rate

[dechamps]

It is now a well-known limitation of the WASAPI Shared backend that the ASIO sample rate has to exactly match the device sample rate as configured in the Windows sound settings, otherwise initialization will fail.

This limitation tends to confuse users, who don't realize the implication that both their input and output devices have to use the same sample rate for WASAPI Shared to work. More generally, this limitation is somewhat surprising in terms of architecture - indeed one would intuitively expect the WASAPI Shared pipeline to provide automatic sample rate conversion.

We should investigate exactly why initialization fails with the WASAPI Shared backend when sample rates don't match. It might be a limitation of WASAPI itself that we can't do anything about, but there is also a possibility that this could be caused by some PortAudio bug, perhaps in the format negotiation logic.

[dechamps]

Took me some time to find it, but here it is, the official word from Microsoft: https://docs.microsoft.com/en-gb/windows/desktop/CoreAudio/device-formats

An application that uses WASAPI to manage shared-mode streams can rely on the audio engine to perform only limited format conversions. The audio engine can convert between a standard PCM sample size used by the application and the floating-point samples that the engine uses for its internal processing. However, the format for an application stream typically must have the same number of channels and the same sample rate as the stream format used by the device.

So there's nothing we can do, that's the way it is with WASAPI Shared. I suspected as such. I'll update the FlexASIO docs.

[dechamps]

Plot twist: turns out this might not be impossible after all. See #32.