Implement BufferSize::Fixed in wasapi, and migrate wasapi to officially-supported Windows crate #669
Conversation
|
I haven't tried cross compiling to windows yet, but looking at windows-rs CI there seems to be no cross compilation job. Their contributing guide doesn't mention targetting the windows platform from Linux either. I don't know whether they really support that feature with the love it deserves. |
|
I've filed an issue, let's see how they react: microsoft/windows-rs#1799 |
|
Okay, I guess we can switch to windows-rs. If there's an issue we can always revert the switch. There are some conflicts for the PR. |
|
Merge conflicts have been resolved. |
|
Can you resolve them via rebase instead? It would be a pity to squash this. |
|
Wait no sorry disregard, it's a history that needs squashing anyways I think. |
|
Does this need any more revisions, or is it good to merge? |
|
Stuff like this makes me worried tbh: dotnet/vscode-csharp#5276 |
|
That's... fair! But I think this case is materially different - if this PR were pulling in a more substantial Microsoft product I'd definitely share your concern, but they've consistently provided open access to the Windows C/C++ headers for multiple decades, even during the peak of their anti-competitive practices in the 2000s. The |
|
@Osspial you are making good points. Let's give them a chance. If they annoy folks enough we can always switch back. |
|
Is this good to merge? |
|
@Osspial can you resolve the merge conflicts? After that it should be good to merge. |
|
I'm not seeing any merge conflicts on my end. |
|
Ah it was because I couldn't rebase merge. Squash merging works. I've merged it! |
…ly-supported Windows crate (RustAudio#669) I migrated to `windows-rs` in this PR since exposing the buffer size range for hardware-offloaded audio processing requires `IAudioClient2`, which isn't exposed in the `winapi` crate, and `winapi` seems to be more or less unmaintained at this point. * Basic type conversion * Make everything compile! * Fix warnings * Implement buffer sizing for wasapi * Convert tabs to spaces * Run cargo fmt * Remove winapi from Cargo.toml * Remove unused commented code from wasapi, and fix lingering TODOs * Fix compile error * Update to windows 0.37.0 * Run rustfmt * Work around rustfmt nested tuple issues * Improve readability of guid comparison code
I migrated to
windows-rsin this PR since exposing the buffer size range for hardware-offloaded audio processing requiresIAudioClient2, which isn't exposed in thewinapicrate, andwinapiseems to be more or less unmaintained at this point.Regarding fixed buffer sizes -
wasapidoesn't seem to support requesting exact audio buffer sizes, but will always get an audio buffer that is at least the size requested. Should that be mentioned in the documentation? Also, the buffer exposed to thedata_callbackdoesn't always match the size of the buffer requested, sincewasapiincrementally updates the buffer as audio gets played, instead of updating it all at once once the buffer is cleared. I'm not sure if that's standard behavior or not but it may also be worth documenting.Related to #544, #534, #667, and #616. @est31, you'd mentioned at #616 (comment) that
windows-rshad some issues with cross-compilation, but from what I can tell from skimming their issue tracker the cross-compilation issues have been addressed. Are there other issues there that are unresolved?