[Bug 59830] New: mmdevapi: IConnector::GetDataFlow / GetDeviceIdConnectedTo return E_NOTIMPL
http://bugs.winehq.org/show_bug.cgi?id=59830 Bug ID: 59830 Summary: mmdevapi: IConnector::GetDataFlow / GetDeviceIdConnectedTo return E_NOTIMPL Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi Assignee: wine-bugs@list.winehq.org Reporter: brian@digital-traffic.net Distribution: --- Created attachment 81106 --> http://bugs.winehq.org/attachment.cgi?id=81106 Test program for reproduction Note: Report is AI Generated / Human Reviewed. SUMMARY IConnector::GetDataFlow and IConnector::GetDeviceIdConnectedTo return E_NOTIMPL instead of valid topology data. Windows returns S_OK with real values for the same calls. Both E_NOTIMPL values are outside the HRESULTs the methods are documented to return. Real-world impact: pro-audio applications that probe endpoint topology to validate an output (e.g. Denon Engine DJ 5.0.0) refuse to use the device. Reproduces on wine-staging 11.10 and on vanilla wine.git d88408468c33dd09c7b3cc9499d0b39ba8023e2f -- not staging-specific. STEPS TO REPRODUCE A standalone MinGW reproducer (test-topology.c, ~130 lines, attached) creates an IMMDeviceEnumerator, gets the default eRender/eConsole endpoint, activates IDeviceTopology, walks to the connector at index 0, and calls GetType, GetDataFlow and GetDeviceIdConnectedTo. The same binary runs on Wine and on Windows. Build (MinGW on Linux): x86_64-w64-mingw32-gcc -O2 -o test-topology.exe test-topology.c \ -lole32 -loleaut32 -luuid Run: wine ./test-topology.exe (Linux + Wine) .\test-topology.exe (Windows) Note on the two test environments below: these are NOT identical hardware. Wine runs on the Linux host; Windows runs as a KVM guest. The Wine-side E_NOTIMPL is unconditional in dlls/mmdevapi/devenum.c (lines 1787 and 1834 both "return E_NOTIMPL;" with no backend interaction), so the divergence is not backend-dependent. The Windows capture is a representative example of what a spec-compliant implementation returns on a real audio endpoint. Wine side: wine-staging 11.10, fresh 64-bit prefix on Arch Linux (kernel 7.0.9, Framework 16 / AMD Ryzen AI 9 HX 370, Radeon 890M iGPU), audio via PipeWire's pulseaudio compat to Wine's pulse driver. Default endpoint is the laptop's built-in HDA codec. Windows reference: Windows 11 25H2 (OS Build 26200.8037) in libvirt/KVM on the same host, virtio HD-audio device (stereo 48 kHz s32le), no DJ hardware attached. ACTUAL OUTPUT (Wine 11.10) == test-topology: Wine mmdevapi IConnector / IDeviceTopology probe == CoInitializeEx -> 0x00000000 (S_OK) CoCreateInstance(MMDeviceEnumerator) -> 0x00000000 (S_OK) GetDefaultAudioEndpoint(eRender,eConsole) -> 0x00000000 (S_OK) IMMDevice::Activate(IDeviceTopology) -> 0x00000000 (S_OK) -- IDeviceTopology probes -- IDeviceTopology::GetConnectorCount -> 0x00000000 (S_OK) connector_count = 1 IDeviceTopology::GetConnector(0) -> 0x00000000 (S_OK) -- IConnector probes (index 0) -- IConnector::GetType -> 0x00000000 (S_OK) ConnectorType = 1 <-- Physical_Internal (hardcoded) IConnector::GetDataFlow -> 0x80004001 (E_NOTIMPL) IConnector::GetDeviceIdConnectedTo -> 0x80004001 (E_NOTIMPL) EXPECTED OUTPUT (Windows 11 25H2 build 26200.8037, identical .exe, virtio HD-audio endpoint) -- IConnector probes (index 0) -- IConnector::GetType -> 0x00000000 (S_OK) ConnectorType = 2 <-- Physical_External IConnector::GetDataFlow -> 0x00000000 (S_OK) DataFlow = 0 <-- In IConnector::GetDeviceIdConnectedTo -> 0x00000000 (S_OK) device_id (connected-to) = {2}.\\?\hdaudio#func_01&ven_1af4&dev_0022&...\elineouttopo DIVERGENCE SUMMARY Per method -- Wine 11.10 vs Windows 11 25H2 (26200.8037) vs documented returns: IDeviceTopology::GetConnectorCount Wine: S_OK, count=1 (hardcoded) Windows: S_OK, count=1 Documented: S_OK / E_POINTER IDeviceTopology::GetConnector(0) Wine: S_OK, empty IConnector Windows: S_OK, real IConnector Documented: S_OK / E_POINTER / E_INVALIDARG IConnector::GetType Wine: S_OK, Physical_Internal (hardcoded) Windows: S_OK, Physical_External Documented: S_OK / E_POINTER IConnector::GetDataFlow *** spec violation *** Wine: E_NOTIMPL Windows: S_OK, In Documented: S_OK / E_POINTER (E_NOTIMPL is not listed) IConnector::GetDeviceIdConnectedTo *** spec violation *** Wine: E_NOTIMPL Windows: S_OK, full device-instance path Documented: S_OK / E_POINTER / E_NOTFOUND / E_OUTOFMEMORY (E_NOTIMPL is not listed) The two methods marked "spec violation" return an HRESULT not listed for them on learn.microsoft.com (see IConnector::GetDataFlow and IConnector::GetDeviceIdConnectedTo). The hardcoded Physical_Internal from GetType is wrong for the virtio HD-audio jack the guest is using, but is at least a spec-legal value. SOURCE POINTERS In dlls/mmdevapi/devenum.c at HEAD d88408468c3: Connector_GetType (devenum.c:1778) FIXME("...partial stub"); *pType = Physical_Internal; return S_OK; Connector_GetDataFlow (devenum.c:1787) FIXME("...stub"); return E_NOTIMPL; Connector_GetDeviceIdConnectedTo (devenum.c:1834) FIXME("...stub"); return E_NOTIMPL; DT_GetConnectorCount (devenum.c:1914) FIXME("...partial stub"); *pCount = 1; return S_OK; DT_GetConnector (devenum.c:1926) FIXME("...partial stub"); returns a freshly-Connector_Create()d empty object for nIndex == 0. Connector_Create (devenum.c:1857) allocates IConnectorImpl with only vtbl + ref; no plumbing of parent IMMDevice flow / id. Connector_GetConnectorIdConnectedTo, Connector_ConnectTo, Connector_Disconnect, Connector_IsConnected and Connector_GetConnectedTo are also pure stubs. They are out of scope for this report (Engine DJ did not call them during testing) but would also need real implementations for a complete IConnector. The existing test scaffold at dlls/mmdevapi/tests/mmdevenum.c:386 (test_connectors()) does not currently catch this -- it "passes" today because the connector count is treated as advisory and the test body short-circuits. REAL-WORLD IMPACT Denon Engine DJ 5.0.0 (Qt6/C++, WASAPI consumer): - App launches, UI renders, library catalogs, BPM analysis runs. - Engine probes WASAPI topology on its startup path. WINEDEBUG=+mmdevapi shows "fixme:mmdevapi:Connector_GetDeviceIdConnectedTo (...) - stub" firing immediately on app launch, before any user interaction. Engine's own log records "GetDeviceIdConnectedTo : Error: UNKNOWN ERROR" 9x during this probe. - Settings > Audio > Output: the Audio Device dropdown shows "No Output channels available". Every enumerated endpoint is rejected during the topology probe, so the user can't select any output at all. - On launch the symptom can also surface as "Mono output devices are not supported. Please select a stereo audio output device." -- same upstream cause; the endpoint is stereo, but the failed topology introspection made Engine treat it as unusable. - Attempting to load a track to a deck throws Engine's internal "EErrorCode 109 / Access denied" from TrackDeckControlLoadWorker::createReader. Confirmed via WINEDEBUG=+ntdll,+file,+seh trace that NO actual STATUS_ACCESS_DENIED is returned by Wine during the failure -- Engine's error code is a catch-all unrelated to filesystem ACLs. - Identical Engine DJ 5.0.0 in a Windows 11 25H2 VM on the same host (virtio HD-audio stereo endpoint, no DJ hardware attached -- same as the Wine run) loads tracks fine. The endpoints differ in driver path but are both 2-channel 48 kHz; Engine's own logs and the standalone reproducer above isolate the divergence to the mmdevapi topology calls, not to the audio endpoint itself. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #1 from Brian G. Shacklett <brian@digital-traffic.net> --- Created attachment 81107 --> http://bugs.winehq.org/attachment.cgi?id=81107 Output from Test Program on Windows running in KVM -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #2 from Brian G. Shacklett <brian@digital-traffic.net> --- Created attachment 81108 --> http://bugs.winehq.org/attachment.cgi?id=81108 Output from test program on Wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81111 --> http://bugs.winehq.org/attachment.cgi?id=81111 Patch that fixes Engine DJ "mono output devices no supported" popup error bug allowing tracks to be loaded/played (In reply to Brian G. Shacklett from comment #0)
Note: Report is AI Generated / Human Reviewed.
REAL-WORLD IMPACT Denon Engine DJ 5.0.0 (Qt6/C++, WASAPI consumer):
Note: work is human generated (emacs enhanced to minimize slop-overflow) Confirming Engine DJ popup error for wine-11.10-b9f5aa42b15: "Mono output devices are not supported. Please select a stereo audio output device." Popup error does not happen until after initial launch which proves app works under some condition. Simply reversing order of audio devices loaded from registry with outputs loaded before inputs allows app to run similar as initial launch. My guess is app expects audio devices ordered based on how Windows loads them from registry vs Wine which may not match and is not robust enough to handle arbitrary order. Setting mono from stereo (default) for winecfg -> Audio -> Speakers does not reintroduce mono popup error so unclear what actually causes it when inputs are loaded first. GetDeviceIdConnectedTo is missing from dlls/mmdevapi/tests/ so test program provided fills part of that gap which should be filled eventually. I'll submit a merge request for patch for now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #4 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81112 --> http://bugs.winehq.org/attachment.cgi?id=81112 Screenshots of bugs (REAL-WORLD-IMPACT) fixed by patch Unclear if bug should be closed as fixed if patch is considered valid because bug title is about GetDeviceIdConnectedTo() E_NOTIMPL which is not addressed by patch. Hopefully a human can help decide that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #5 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81113 --> http://bugs.winehq.org/attachment.cgi?id=81113 Patch overriding previous containing minor human error Latest patch overrides previous despite both working for Engine DJ. Please forgive my human error. I will submit this one for MR. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #5)
I will submit this one for MR.
https://gitlab.winehq.org/wine/wine/-/merge_requests/11083 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #7 from Brian G. Shacklett <brian@digital-traffic.net> --- I was able to run inside of a patched build and can confirm that this solved the audio channel problems. I was able to load a track and play it. This also seemingly unlocked the ability to add tracks to my "collection" and render stems, which is a significant bonus. Apologies for the "slop". E_NOTIMPL on the mentioned methods felt like a smoking gun, but they turned out to be a red herring. A good lesson in humility here, I suppose. I'll do my best not to make the same mistake again. The code in the MR solves the real world problem. I'm perfectly happy with this bug being closed at your discretion. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #8 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Brian G. Shacklett from comment #7)
I was able to run inside of a patched build and can confirm that this solved the audio channel problems. I was able to load a track and play it. This also seemingly unlocked the ability to add tracks to my "collection" and render stems, which is a significant bonus.
Awesome. Thanks for tests and human feedback. Glad its working.
Apologies for the "slop". E_NOTIMPL on the mentioned methods felt like a smoking gun, but they turned out to be a red herring. A good lesson in humility here, I suppose. I'll do my best not to make the same mistake again.
No worries. It's also an LLM mistake/problem so hopefully this will teach them how to better interact with Wine project if they are targeting it for help. Bug report is very useful and appreciated but patches and merge requests are discouraged because they are may be too risky for Wine's legal objectives. https://gitlab.winehq.org/wine/wine/-/wikis/Developer-FAQ
The code in the MR solves the real world problem. I'm perfectly happy with this bug being closed at your discretion.
Thanks for confirming. Once merged either you or someone with elevated privileges may close as FIXED/RESOLVED. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59830 --- Comment #9 from Stian Low <wineryyyyy@gmail.com> --- Duplicates: https://bugs.winehq.org/show_bug.cgi?id=43652#c5 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla