[Bug 28109] New: winmm capture tests fail on some machines
http://bugs.winehq.org/show_bug.cgi?id=28109 Summary: winmm capture tests fail on some machines Product: Wine Version: 1.3.26 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com On my Asus G60JX laptop, with Ubuntu 11.04, winmm's capture tests fail with err:winmm:WINMM_OpenDevice Activate failed: 80004005 capture.c:148: Test failed: waveInOpen(1): format=8000x 8x1 flags=50000(CALLBACK_EVENT) rc=MMSYSERR_ERROR(Undefined external error.) err:winmm:WINMM_OpenDevice Activate failed: 80004005 capture.c:148: Test failed: waveInOpen(1): format=8000x 8x1 flags=50008(CALLBACK_EVENT|WAVE_FORMAT_DIRECT) rc=MMSYSERR_ERROR(Undefined external error.) This is a bit like bug 27895. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #1 from Dan Kegel <dank(a)kegel.com> 2011-08-17 09:23:52 CDT --- Created an attachment (id=36012) --> (http://bugs.winehq.org/attachment.cgi?id=36012) WINDEBUG=+winmm,+mmdevapi,+alsa make capture.ok Also, on this machine, in winecfg, clicking on "test audio" yields err:winmm:WINMM_OpenDevice Activate failed: 80004005 and makes just a clicking sound, not the usual tweedle sound. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 Andrew Eikum <aeikum(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum(a)codeweavers.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase CC| |austinenglish(a)gmail.com Severity|normal |trivial -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |normal --- Comment #2 from Dan Kegel <dank(a)kegel.com> 2011-08-17 13:21:01 CDT --- Test failures are not trivial. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle(a)yahoo.fr -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #3 from Austin English <austinenglish(a)gmail.com> 2012-10-17 23:03:50 CDT --- I get this on debian/testing, and Michael Stefaniuc does as well on Fedora. I'll attach an updated log. wine-1.5.15-54-g968a1e9 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #4 from Austin English <austinenglish(a)gmail.com> 2012-10-17 23:04:31 CDT --- Created attachment 42178 --> http://bugs.winehq.org/attachment.cgi?id=42178 WINEDEBUG=+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+alsa -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #36012|0 |1 is obsolete| | Attachment #36012|WINDEBUG=+winmm,+mmdevapi,+ |WINDEBUG=+winmm,+mmdevapi,+ description|alsa make capture.ok |alsa make capture.ok -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t Component|mmdevapi |winmm&mci -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #5 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2012-10-31 06:55:39 CDT --- Please apply at least [PATCH 1/3] winmm: Prefer using MMSYSERR_* over AUDCLNT_E_* from mmdevapi. [PATCH 2/3] winmm: Avoid generic MMSYSERR_ERROR during initialisation. [and optionally patch 3] starting with http://www.winehq.org/pipermail/wine-patches/2012-October/119353.html and report back. The cause is always the same. Scanning all devices causes side effects as some devices (PulseAudio) block access to other ones (hw:0) for some time. The patch does not preventthat, but now winmm yields error codes such as MMSYSERR_ALLOCATED compatible with native. The test suite knows such "normal" error codes and won't complain like about MMSYSERR_ERROR. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #6 from Austin English <austinenglish(a)gmail.com> 2012-10-31 13:35:55 CDT --- (In reply to comment #5)
Please apply at least [PATCH 1/3] winmm: Prefer using MMSYSERR_* over AUDCLNT_E_* from mmdevapi. [PATCH 2/3] winmm: Avoid generic MMSYSERR_ERROR during initialisation. [and optionally patch 3] starting with http://www.winehq.org/pipermail/wine-patches/2012-October/119353.html and report back.
The cause is always the same. Scanning all devices causes side effects as some devices (PulseAudio) block access to other ones (hw:0) for some time.
The patch does not preventthat, but now winmm yields error codes such as MMSYSERR_ALLOCATED compatible with native. The test suite knows such "normal" error codes and won't complain like about MMSYSERR_ERROR.
austin(a)debian53:~/wine-git/dlls/winmm/tests$ make test ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so capture.c && touch capture.ok capture.c:150: Test failed: waveInOpen(2): format=11025x 8x1 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=11025x 8x2 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=11025x16x1 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=11025x16x2 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=22050x 8x1 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=22050x 8x2 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=22050x16x1 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=22050x16x2 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=44100x 8x1 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=44100x 8x2 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) capture.c:150: Test failed: waveInOpen(2): format=44100x16x1 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT(The specified format is not supported or cannot be translated. Use the Capabilities function to determine the supported formats.) fixme:adpcm:ADPCM_StreamOpen We don't support encoding yet make: *** [capture.ok] Error 11 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #7 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2012-10-31 15:06:25 CDT --- WAVE_MAPPED -> WAVERR_BADFORMAT That is as good as it can get, I'm afraid. That case is not changed by my patch. The mapper is expected to return BADFORMAT when it cannot find anything suitable. And nothing suits because the underlying plughw device does not open (for some time). Maybe a distinct work-around patch(hack) could observe that specific trouble with the underlying devices and remap (pass-through) the error, or wait some time and retry... In your previous log, there were 3 kind of errors: capture.c:150: Test failed: waveInOpen(2): format=22050x16x2 flags=50004(CALLBACK_EVENT|WAVE_MAPPED) rc=WAVERR_BADFORMAT capture.c:150: Test failed: waveInOpen(2): format=44100x 8x1 flags=50000(CALLBACK_EVENT) rc=MMSYSERR_ERROR(Undefined external error.) capture.c:150: Test failed: waveInOpen(2): format=44100x 8x1 flags=50008(CALLBACK_EVENT|WAVE_FORMAT_DIRECT) rc=MMSYSERR_ERROR(Undefined external error.) Your test result shows that my patches silenced the ones not involving the wave mapper, because there winmm returns a a compatible MMSYSERR_* (e.g. ALLOCATED). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=28109 --- Comment #8 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2012-11-01 08:19:26 CDT --- >WAVE_MAPPED -> WAVERR_BADFORMAT One test to perform on a w9x machine (no kernel mixer): 1. waveInOpen(device=2, flags=0) then without waveClose: 2. waveInOpen(device=2, flags=WAVE_MAPPED) It could be that this behaves differently from waveInOpen(device=-1=WAVE_MAPPER, ...) I.e. when asked for the specific device #2 and that is allocated, then native might realize that there's no point in trying out msacm codecs and it might return MMSYSERR_ALLOCATED instead of BADFORMAT. Another test on w9x may be to disable all sound cards via the menu, then run the winmm tests. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 --- Comment #9 from Austin English <austinenglish(a)gmail.com> --- For me on Fedora 19 with pulseaudio: [austin(a)localhost tests]$ make test ../../../tools/runtest -q -P wine -T ../../.. -M winmm.dll -p winmm_test.exe.so capture && touch capture.ok capture.c:456: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) capture.c:474: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) capture.c:498: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) capture.c:522: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) capture.c:546: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) capture.c:598: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) capture.c:622: Test failed: waveInOpen(1): returned: MMSYSERR_ALLOCATED(The specified device is already in use. Wait until it is free, and then try again.) (nothing is actually using the microphone, fwiw) with pasuspender, it works fine: [austin(a)localhost tests]$ rm *ok ; pasuspender make capture.ok ../../../tools/runtest -q -P wine -T ../../.. -M winmm.dll -p winmm_test.exe.so capture && touch capture.ok [austin(a)localhost tests]$ other sound tests pass under pulseaudio on my machine. wine-1.7.15. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 --- Comment #10 from Austin English <austinenglish(a)gmail.com> --- Created attachment 47860 --> https://bugs.winehq.org/attachment.cgi?id=47860 WINEDEBUG=+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+alsa make capture.ok -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 --- Comment #11 from Andrew Eikum <aeikum(a)codeweavers.com> --- Created attachment 47873 --> https://bugs.winehq.org/attachment.cgi?id=47873 winmm/tests: Accept MMSYSERR_ALLOCATED for more tests Looks like we can't open the hardware device directly if PA has recently used the device. On the rendering side, we detect this while probing for devices, so the hw device is never enumerated. For capture, the hw device appears to work during probing, but then fails to open later on after we've run the waveIn tests on the PA device. Two options seem reasonable. Change the tests to accept MMSYSERR_ALLOCATED as a valid return code and continue, or Attempt to do something intelligent in winealsa.drv such that we never enumerate this device, since PA kind of owns it. The former seems like the best option to me, since we can't predict which hw device PA will choose to occupy, and we don't want to inaccurately restrict which devices the user can choose to record with in Wine. In fact, we already accept MMSYSERR_ALLOCATED for some tests, so let's just do that for all waveInOpen calls. Attached patch should fix this. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 --- Comment #12 from Austin English <austinenglish(a)gmail.com> --- (In reply to Andrew Eikum from comment #11)
Created attachment 47873 [details] winmm/tests: Accept MMSYSERR_ALLOCATED for more tests
Looks like we can't open the hardware device directly if PA has recently used the device. On the rendering side, we detect this while probing for devices, so the hw device is never enumerated. For capture, the hw device appears to work during probing, but then fails to open later on after we've run the waveIn tests on the PA device.
Two options seem reasonable.
Change the tests to accept MMSYSERR_ALLOCATED as a valid return code and continue, or
Attempt to do something intelligent in winealsa.drv such that we never enumerate this device, since PA kind of owns it.
The former seems like the best option to me, since we can't predict which hw device PA will choose to occupy, and we don't want to inaccurately restrict which devices the user can choose to record with in Wine.
In fact, we already accept MMSYSERR_ALLOCATED for some tests, so let's just do that for all waveInOpen calls.
Attached patch should fix this.
Seems to work here. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #13 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with wine-5.11? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Austin English <austinenglish(a)gmail.com> --- (In reply to joaopa from comment #13)
Does the bug still occur with wine-5.11?
It's green pretty much across the board according to https://test.winehq.org/data/tests/winmm:capture.html. Works here as well, assuming fixed. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28109 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 5.13. -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla