[Bug 28109] New: winmm capture tests fail on some machines

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@winehq.org ReportedBy: dank@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.

Show replies by date

wine-bugs＠winehq.org

17 Aug 17 Aug

2:23 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #1 from Dan Kegel dank@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.

wine-bugs＠winehq.org

3:56 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Andrew Eikum aeikum@codeweavers.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com

wine-bugs＠winehq.org

6:12 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Austin English austinenglish@gmail.com changed:

wine-bugs＠winehq.org

6:21 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Dan Kegel dank@kegel.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |normal

--- Comment #2 from Dan Kegel dank@kegel.com 2011-08-17 13:21:01 CDT --- Test failures are not trivial.

wine-bugs＠winehq.org

9:03 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Sylvain Petreolle spetreolle@yahoo.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr

wine-bugs＠winehq.org

18 Oct 18 Oct

4:03 a.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #3 from Austin English austinenglish@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

wine-bugs＠winehq.org

4:04 a.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #4 from Austin English austinenglish@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

wine-bugs＠winehq.org

4:04 a.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Austin English austinenglish@gmail.com changed:

wine-bugs＠winehq.org

26 Oct 26 Oct

9:22 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Jörg Höhle hoehle@users.sourceforge.net changed:

wine-bugs＠winehq.org

31 Oct 31 Oct

11:55 a.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #5 from Jörg Höhle hoehle@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.

wine-bugs＠winehq.org

6:35 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #6 from Austin English austinenglish@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@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

wine-bugs＠winehq.org

8:06 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #7 from Jörg Höhle hoehle@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).

wine-bugs＠winehq.org

1 Nov 1 Nov

1:19 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #8 from Jörg Höhle hoehle@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.

wine-bugs＠winehq.org

22 Mar 22 Mar

10:03 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #9 from Austin English austinenglish@gmail.com --- For me on Fedora 19 with pulseaudio:

[austin@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@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@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.

wine-bugs＠winehq.org

10:06 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #10 from Austin English austinenglish@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.

wine-bugs＠winehq.org

24 Mar 24 Mar

2:45 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #11 from Andrew Eikum aeikum@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.

wine-bugs＠winehq.org

8:53 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

--- Comment #12 from Austin English austinenglish@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.

WineHQ Bugzilla

24 Jun 24 Jun

12:28 a.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

joaopa jeremielapuree@yahoo.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr

--- Comment #13 from joaopa jeremielapuree@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.

WineHQ Bugzilla

10 Jul 10 Jul

11:59 a.m.

New subject: [Bug 28109] winmm capture tests fail on some machines

Austin English austinenglish@gmail.com changed:

--- Comment #14 from Austin English austinenglish@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.

WineHQ Bugzilla

17 Jul 17 Jul

9:34 p.m.

New subject: [Bug 28109] winmm capture tests fail on some machines