1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
hda sound capture broken with VNC
QEmu is being used to run the Wine conformance tests in Windows virtual machines. Wine's conformance tests check the behavior of various Windows APIs and verify that they behave as expected. One of the tests checks the behavior of the mmdevapi sound capture APIs. This test works fine on real hardware and also works fine in various QEmu VMs but fails in some others. Further investigation showed that:
* The mmdevapi:capture tests work on the two Vista VMs. Those use the ac97 sound card and are configured for VNC access to the VM.
* The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an hda sound card and are configured for VNC access to the VM (so '-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0').
* Furthermore configuring the VM for Spice access fixes the mmdevapi:capture test (so replacing -vnc with '-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'), this even if no client connects to the VM.
So in effect the -spice and -vnc options change the behavior of the sound device.
To reproduce this bug:
1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt).
2. Set it up for access using VNC.
3. Copy the attached mmdevapi_test.exe file to it. (*)
4. Run the tests as follows:
mmdevapi_test.exe capture
If you see these 'Test Failed' lines then the bug is still present:
capture.c:586: Returned latency: 5.8050 ms
capture.c:178: Test failed: Position 1015 expected 0
capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked: 448
capture.c:228: Test failed: Position 2167 expected 1463
capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames locked: 448
capture.c:256: Test failed: Position 2167 expected 1463
capture.c:292: GetBufferSize 21996 period size 448
capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames locked: 448
capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996
capture.c:313: Test failed: Position 4215 gap 2304
capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames locked: 448
capture.c:333: Test failed: Position 5303 expected 4663
capture.c:334: Test failed: flags 1
capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames locked: 448
capture.c:358: Test failed: Position 7351 expected 5111
capture.c:359: Test failed: flags 1
In case it helps, here is the source of mmdevapi_test.exe:
https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178
So far I have confirmed that this bug is present in QEmu as shipped in the following Debian packages:
* qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 + linux-image-3.16.0-4-amd64 3.16.7-ckt11-1+deb8u3
* qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1
(*) As alternatives to using the attached binary you can:
- Compile it from Wine's source. See:
https://source.winehq.org/git/wine.git/
- Or download the latest WineTest binary from https://test.winehq.org/builds/winetest-latest.exe
And extract the mmdevapi_test.exe from there:
winetest.exe -x tests
tests\mmdevapi_test.exe capture
On Debian this is still present in QEMU 1:2.7+dfsg-3+b1 with the 4.8.11-1 Linux kernel.
So no change in the past 5 quarters :-(
So I'm attaching a tar file containing standalone and somewhat minimalist source code for reproducing this issue. Just compile it with MinGW by typing 'make', send the capture.exe binary to the VM and run it. Again if you see 'Test failed' messages the bug is still present.
As an alternative to compiling the source code yourselves, I have attached the capture.exe binary.
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.
Thank you and sorry for the inconvenience.
This is an automated cleanup. This bug report has been moved
to QEMU's new bug tracker on gitlab.com and thus gets marked
as 'expired' now. Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/70
|