ao_wasapi: Use ks.h public abi instead of ksuuid.h #9667
Conversation
ks.h is the pubic api provided by microsoft while ksuuid.h is undocumented. To use ks.h api, we need to link against ksuser library. So add ksuer detection to waf and meson. Fixes: mpv-player#9627 Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
|
Would it be sufficient to simply change the the wasapi check to only look for the ksuser library? You could remove the wasapi.c fragment altogether in that case. I don't really know anything about windows but if ksuser being available guarantees that you have AudioClient, using the library check alone would be better. |
|
|
|
Cool, seems fine in that case. I'll let someone that actually knows about windows chime in. |
|
ping？@Dudemanguy it is blocking windows build. |
Blocking to whom? AFAIK it only blocks with mingw master, no? Why is the Also, which functions/symbols/whatever exist at the lib which are now needed and previously we didn't need the lib for them? |
ksuser is always there since windows95, but it is a common practice to detect the existence of a library before using it.
|
|
The building issue actuall helped us discovered that long lasting problem. As |
It is blocking latest MSYS2 users. |
Don't check a lib if it exists since win95 and also in all current+historic mingw versions (does it?).
Who is "us"?
That's not a factor. MSYS2 uses master of everything, and we can't guarantee to be compatible with bleeding edge packages, unless noted otherwise. Our aim is to be compatible with release versions, preferably also older release version which are still out there, and hopefully bleeding edge too, but that's a bonus. Either way, what happens with older mingw versions? |
|
I don't seem to have a new enough meson version on the latest msys2, but waf builds mpv fine for me with mingw-w64-x86_64-headers-git 9.0.0.6373.5be8fcd83-1. |
|
Found it, needed to install mingw-w64-meson, not one of the other versions. Also builds fine for me with meson. (Not to derail this PR, just chiming in since I happen to use msys2.) |
Yep, it's a foundation part of Windows sound API.
Well, I should say me :-)
Nothing happens, ksuser detection is expected to pass on all mingw versions. |
Hmm I just found that mingw had pushed a fix in master to workaorund this build issue. However it reveals a actual problem that we are relying on a behavior that is not guaranteed to be last forever. It is a correction of API misuse :-) |
I meant will it build and work as expected? And as I said, remove the detection. It's not needed - at least not the detection of the lib. The question is how are the symbols resolved to the runtime lib (currently), and does older mingw also able to resolve them from the lib at runtime? And if not - what happens then?
mingw has been changing since #9627 was opened (well, before, which resulted in that issue), and it could change a bit more, which is why we don't care too much about bleeding edge, especially in a state of flux. We should wait till it settles first IMO. |
The general rule of a build system is always test library availability before linking it. By doing this we can avoid tons of user environmental issues. Although it should be safe to assume ksuser.dll is exist when we can find relevant headers, but it is still a assumption. Yes, for older mingw it still work as this family of symbol is declared in ks.h as external symbol.
mingw is always trying to align with official MS API. So the safest way for us (well, at least me) is just following Microsoft's recommended usage, not depending on some mingw trick. |
|
@jeeb made a thorough analysis here #9627 (comment) He'll comment here later. |
|
Similar to what I said in #9627, but it looks like mingw-w64 hasn't changed the behavior since then (i.e. it still works) so we don't have to change any code on our end. Plus this is old. |
ks.h is the pubic api provided by microsoft while ksuuid.h
is undocumented.
To use ks.h api, we need to link against ksuser library. So
add ksuer detection to waf and meson.
Fixes: #9627