On Fri Jul 25 20:35:01 2025 +0000, Giovanni Mascellani wrote:
It would be weird to have a Wine specific interface, I think if
channel mapping is unsupported in WASAPI that is supposed to be done in users. I don't think that reasoning applies here; the "users" here are not regular Windows programs, but other Wine components. I don't think there is any reason to believe that on Windows those components (like dsound, qcap, winmm) are implemented on top of the public mmdevapi interface (especially considering how the public mmdevapi interface is constrained); it's more likely they have access to internal interfaces, so I don't see it wrong in principle to have an internal interface in Wine too. I'd be happy to avoid the internal interface if possible, but it's not really obvious that it's possible to me.
it looks like at least stereo format is advertised on 5 or 7 channel
systems (while 5 or 7 channels vs other channel counts are not tested); Yes, that's something to test. Another reason for putting this MR to draft mode. Hopefully in the next days I should receive some 7.1-capable hardware to test.
Also, see
https://learn.microsoft.com/en-us/windows/win32/coreaudio/audclnt-streamflag..., AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM flag description mentions "channel matrixer". Maybe there are actually some ways to control channel translation at least on newer audio client interfaces? I had missed it, and it's certainly interesting. I had noticed that AUDCLNT_STREAMFLAGS_RATEADJUST allows setting an arbitrary sampling rate, but not an arbitrary channel count. If AUTOCONVERTPCM indeed allows setting both an arbitrary sampling rate and channel count like the documentation seems to imply (I will check it), then it does half of the work of the private interface I added to this MR. Unfortunately it doesn't do the other half, i.e., the equivalent of `IsFormatSupported()`, because you can't pass stream flags to it. A possible way forward might be to rely on the fact that in practice all audio backends support all possible sample format/channel count/sampling rate combinations, therefore there is nothing to check. I can try to rewrite this MR with this philosophy and see what happens.
Maybe the best way forward would be to remove the check for render
client for now (as far as I understand the initial trigger for the change only depends on that check for capture)? Ok, I can do that. It doesn't seem a terrible regression to handle, since bisection should point to the relevant commit rather quickly, but taking the safest path is probably not a bad idea either.
I thought FNA-XNA/FAudio works on Windows in principle, am I wrong?
Also, I don't know how native dsound / xaudio are implemented on Windows, but it would be weird if that was using some direct driver interfacing these days bypassing WASAPI, maybe using something undocumented there of course which we are not aware about. Did you test all the same with audio IAudioClient3? It might behave overall different in theory. In any case, custom interfaces are quite not favoured in Wine, in this case it looks rather obvious if WASAPI really doesn't allow for those conversions, through some flags or else, that should be done in the users of those.