wasapi: Enable resampling and rate adjustment

[yeah-its-gloria]

this should allow resampling sample rates that are too quirky for native hardware by the WASAPI server 👍

[yeah-its-gloria]

Currently this still fails because of format checks, I will look into this and see how I can fix this solved this

[kaezrr]

I have tested this and this works, it allows me to request custom sampling rates in windows that was otherwise locked to only one single sampling rate conversion.

This solves issue #593 that has been open for almost 5 years now.

@roderickvd you might remember me from the Rust Audio discord, i was ranting about the resampling issue on Windows and you recommended me to use rodio instead.

I can vouch that this PR works, you might be interested to take a look

[kaezrr]

Tested on a windows VM, works as intended, solves #593

[roderickvd]

Thank you for your contribution!

I'd like that we altogether think about this in the context of API and expectations. Let's say that a device supports 48 and 192 kHz, and is configured to use 192 kHz by default. Now when we request 48 kHz it's indeed the question if we should:
a. fail like we do currently
b. silently resample

Rationale for A: we request 48 kHz explicitly and can't get that, so that's a failure.
Rationale for B: out-of-the-box experience for users.

Don't take this as a final decision, but currently I'm leaning towards A (keeping as-is). When users want resampling, they can do so explicitly. For example, by:

• catching an open stream error and falling back to the default stream configuration instead, then doing resampling themselves
• using Rodio which is intended as a batteries-included audio crate, unlike cpal which is more low-level
• using extension traits in the future (see #1074 for an example), that could allow users to explicitly opt-in to resampling behavior

While we're considering this, please find my review comments inline. Please add a changelog entry as well.

[yeah-its-gloria]

Apparently PulseAudio transparently converts formats already, and PipeWire requires you to attach SPAs to your stream for conversion regardless, so I don't see the particular issue with automatic resampling here.
The main reason AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM isn't standard is that it wasn't a thing in WASAPI until Windows 10 - even though WASAPI (and shared mode being default!) was part of Windows since Vista.

catching an open stream error and falling back to the default stream configuration instead, then doing resampling themselves

Resampling can be annoying to implement, and APOs might do a better job at it (by, for example, using the sound hardware).

using Rodio which is intended as a batteries-included audio crate, unlike cpal which is more low-level

I don't think low-level APIs should just ignore features implemented by the APIs beneath them (look right below).

using extension traits in the future (see #1074 for an example), that could allow users to explicitly opt-in to resampling behavior

Once implemented, sure thing.