http://bugs.winehq.org/show_bug.cgi?id=30147
Bug #: 30147
Summary: mmdevapi: incorrect capture overrun handling
Product: Wine
Version: 1.3.25
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mmdevapi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
CC: m.b.lankhorst(a)gmail.com
Classification: Unclassified
Created attachment 39320
--> http://bugs.winehq.org/attachment.cgi?id=39320
mmdevapi capture test from native w7 machine
Most wineXYZ audio drivers do not handle mmdevapi capture overrun correctly. In
particular, the ALSA & OSS drivers randomly overwrite old with new data,
depending on the read pointer within the capture buffer.
Native roughly supports, with some quirks, a scenario like:
Initialize(duration=Xms);
Start;
Sleep(X+Yms); /* Y extra spare time */
Stop; /* optional, buffer is full now */
repeat GetBuffer/ReleaseBuffer until (hr != S_OK);
The goal is to obtain one buffer (~Xms) full of data.
The attached log from a w7 machine shows what packet gets recorded at what time
by tracing GetBuffer's performance counter output parameter (qpc). The key
data points are:
>capture.c:544: rate: 48000
>capture.c:293: GetBufferSize 23941 period size 480
>capture.c:248: Sleep.1 position 480 pad 16800 flags 0, frames locked: 480
>capture.c:250: sleep qpc=67335132
>capture.c:293: GetBufferSize 23941 period size 480
>capture.c:303: Overrun position 1440 pad 23941 flags 1, frames locked: 480
>capture.c:305: overrun qpc=67355139
This position and qpc jump of exactly one period I don't understand.
>capture.c:331: Cont'ed position 1920 pad 23461 flags 0, frames locked: 480
>capture.c:333: cont'ed qpc=67365133
>qpc=67375139 0 position 2400 pad 22981 flags 0, next 480, frames locked: 480
>qpc=67385135 1 position 2880 pad 22501 flags 0, next 480, frames locked: 480
Note how position correlates with 10ms increments of qpc (in µs).
>qpc=67795152 42 position 22560 pad 3301 flags 0, next 480, frames locked: 480
>qpc=67805153 43 position 23040 pad 2821 flags 0, next 480, frames locked: 480
>qpc=67815148 44 position 23520 pad 2341 flags 0, next 421, frames locked: 421
>qpc=67823919 45 position 23520 pad 1920 flags 0, next 59, frames locked: 59
>qpc=67825154 46 position 24000 pad 1861 flags 0, next 480, frames locked: 480
>qpc=67835147 47 position 24480 pad 1381 flags 1, next 421, frames locked: 421
>qpc=68085155 48 position 36480 pad 960 flags 1, next 480, frames locked: 480
>capture.c:352: Test failed: Valid IAudioCaptureClient_GetBuffer: 08890001
>qpc=68085155 49 position -1 pad 480 flags 1, next 0, frames locked: 0
qpc indicates that old packets are being delivered until iteration <48, where
another position jump occurs.
Summary:
- I don't know where native's 23941 frames buffer comes from.
It's neither a multiple of the period size nor of 1024.
- Upon underrun, a DISCONTINUITY is immediately signaled and one
packet is skipped. The latter is weird. (I'm wondering whether
native overwrites one packet within the circular buffer as an
overrun detector, then skips it?).
+ Then, almost a full buffer of old packets can be retrieved with
GetBuffer.
- While the full buffer is 49 * 480 + 421, only 48 * 480 + 421 frames
can be retrieved with a qpc indicating pre-overrun times.
- The last old packet is flagged with DISCONTINUITY too (iteration 47).
I'd have expected solely the following one to bear this mark.
+ When there's room again in the buffer, GetBuffer yields new packets
(iteration 48). Both position and qpc reflect the overrun gap that
appears to have last for 250ms. DISCONTINUITY is set too.
- There's some strange packet splitting at iterations 44-45 that may
correspond to a wrap-around of native's buffer.
I wonder why native does not limit buffer to multiples of period size.
- Note that the position 23520 of the 59 frames fragment rest is the
same as that of the previous 421 frames packet. A bug in native?
The qpc is different and looks ok.
+ GetNextPacket exactly matches the following GetBuffer, even when it
yields less than one packet, e.g. 421/59/480.
- GetCurrentPadding >= period size does not imply a successful GetBuffer,
see iteration 49. Only GetNextPacket correlates fine. A bug in native?
--
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=30110
Bug #: 30110
Summary: Mass effect steam
Product: Wine
Version: 1.4-rc6
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: Monoboy4ik(a)gmail.com
Classification: Unclassified
Game works fine but sometimes after 1-2 hours playing game freezes. No errors
in the console does not appear. Help please
--
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=29809
Bug #: 29809
Summary: Hype the Time Quest Installer Goes Over 100%
Product: Wine
Version: 1.3.16
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jthomas97411(a)yahoo.com
Classification: Unclassified
Wine 1.3.16 is as far back as I tested. For 1.3.16, 1.3.20, 1.4 rc 1, and 1.4
rc 2, if you uncheck the Microsoft DirectX Media check, this will allow the
installer to succeed, whereas if you don't uncheck that, it will fail.
When it fails (DirectX check left checked), it stops at about 100%. When it
succeeds (DirectX check unchecked), it goes to 116%, in the case of the
versions mentioned above.
There were some versions there for a while, somewhere not too far after 1.3.29,
that went to 117% when you didn't uncheck the DirectX test and they failed, and
when you did uncheck the DirectX test, the installer stopped at 100% and
succeeded. Whereas with these other versions it doesn't go over if you _don't_
uncheck it and does go over if you _do_ uncheck_ it. It still held true that
unchecking let it succeed and leaving it checked caused it to fail.
So this is a separate bug from the installer simply crashing.
Notice how this is different than the DirectX check bug: 29806. This is about
the installer going over 100%.
I get this 9 times in terminal from when the installer crashes in the case of
1.3.16, 1.3.20, 1.4 rc 1, and 1.4 rc 2:
fixme:advpack:ExecuteCabW Cab archive not extracted!
Jake
--
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=31055
Bug #: 31055
Summary: Sonic The Hedgehog 4 very slow on multicore cpu
Product: Wine
Version: 1.5.7
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: viny_viny304(a)hotmail.com
Classification: Unclassified
Sonic The Hedgehog 4 episode 1 and 2 is very slow on multicore cpus. Used
schedtool (to define the affinity. e.g. schedtool -a 0x1 -e wine ... ) the
performance improves considerably but still keeps a bit out of normal.
--
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=20232
Summary: mciwave breaks on MSDN example
Product: Wine
Version: 1.1.30
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winmm&mci
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
I'm reviewing mciwave and mciseq and found numerous issues. Concurrently, I'm
augmenting the MCI testsuite. I've attached my current mciwave
work-in-progress tests to give you an early insight into my work.
The tests so far confirm my model of MCI: I view it like an old-fashioned tape
deck with buttons, which you can press in any order. Still there's error
checking, e.g. you can't resume when stopped. Like a tape deck, you can switch
from playing to recording at any time.
Oddly, you can combine fast forward and play in one command, but not rewind
with play.
The attached tests work fine on (at least one machine with) MS-Windows, but
cause Wine to fail and hang in multiple ways. You've been warned!
I'd be pleased if people could run the tests on more instances of MS-Windows.
I plan to strip down this test file until it at least does not hang anymore in
Wine. Then only can it be submitted. Concurrently, I can submit patches to
the mci* codebase.
Current issues with the mci code in Wine are:
- not distinguishing between STOPPING and STOPPED, PLAYING and GOING TO PLAY,
etc.;
- seriously broken asynchronous execution;
- non-error-proof use of InterlockDecrement. It must only be called
when waveInAddBuffer and waveOutWrite succeed, as those cause
callbacks to happen;
- RIFF .wav file not always correctly written;
- the mmio is as much as resource as the wave device and must be
properly released (mmioAscend, not only when saving);
- many items here and there:
+ bogus 44000Hz frequency;
+ premature return (in mcicda);
+ conversion between #bytes and samples;
+ switching fInput while playing;
+ copy&paste errors (InterlockedDecrement need be initialised
differently when recording and playing)
The major issue is concurrency. There I'm not sure how to proceed and rewrite
mciwave (and mciseq and mcicda).
o One model, Erlang-like, which the OSS driver also implements, is one thread
per play and exclusively using message passing to receive commands. This would
simplify NOTIFY everywhere. It clearly offers the advantage of being closest
to the sequential execution model that is easy to reason about. IMHO, it does
not play nicely with the pause command (state machine).
o Continue as currently written, but then think twice and even 3-7 times about
how to perform locking among the concurrent threads:
- Put InterlockIncrement() to more uses?
- Put Events to more uses?
- Unlike mciavi, there's no CriticalSection in mciwave and mcicda, yet
I'm unconvinced that the current synchronisation via volatile dwStatus
can suffice.
- But then, identifying the critical sections will be tedious and error prone.
o Combinations of both, e.g. one thread per play or record (not unlike the
present code), and dealing (correctly) with PAUSE, STOP and RESUME inside it
(via e.g. events to restart a paused thread, or indirectly, by relying on the
callbacks+events sent when invoking waveOutRestart and waveInStart -- is it
legal at all to call those from a different thread)?
o Is there any other concurrency model suitable in Wine?
Regards,
Jörg Höhle
--
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=31232
Bug #: 31232
Summary: The Way Things Work 2.0 installer froze after finished
copying files
Product: Wine
Version: 1.1.21
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: Nachanon_Vetjasit(a)hotmail.com
Classification: Unclassified
Regression SHA1: 54d7c8012d1d7369a56779955ced5a09e448a1cd
When started The Way Things Work 2.0 installer (setup.exe),
the setup proceeds normally, through the welcome screen,
quicktime installer prompt (though QuickTime 16bit 2.1.1 installation didn't
work [bug #18260]),
installation options (express/custom), files copying progress window.
But as soon as the file copying window disappeared, the installer froze, no
screen repainting, no message from WINE's console.
(Normally this stage should be creating program groups and ends at the 'Setup
Complete' window)
54d7c8012d1d7369a56779955ced5a09e448a1cd is first bad commit
commit 54d7c8012d1d7369a56779955ced5a09e448a1cd
Author: Dmitry Timoshkov <dmitry(a)codeweavers.com>
Date: Wed Apr 29 15:17:35 2009 +0900
explorer: Initialize the Progman DDE interface when starting explorer.
:040000 040000 4a347655bb6f41b8b8377d8e3e3e25c1551d1730
05513d15b76a99fe5033c4422a82008667425088 M programs
With WINE before this commit, the installation would continue, with WINE's
Program Manager (progman)
popped up with a dialog from the setup program: "Unable to start DDE
communication with Program Manager." [Abort/Retry/Ignore]
If clicked 'Ignore' (aka. continue despite the error), this step will be
repeated for another five time, each time leaving one Program Manager window
opened (6 window total at the end).
And finished with 'Setup Complete' window.
Note:
The Way Things Work is a 16-bit application, and supports Windows 3.1.
Tested using WINE's Windows version 98.
WINE: wine-1.1.21 source distribution
System: Debian GNU/Linux 5.0 "Lenny" i386 (Intel Pentium 4 2.66GHz)
--
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=31283
Bug #: 31283
Summary: I Love Science! cannot detect it's CD
Product: Wine
Version: 1.5.6
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: Nachanon_Vetjasit(a)hotmail.com
Classification: Unclassified
Created attachment 41094
--> http://bugs.winehq.org/attachment.cgi?id=41094
WINE 1.5.6 +relay,+seh,+tid
When started DK's I Love Science (.wine/drive_c/Program Files/DK Multimedia/I
Love Science!/ilovesci.exe), instead of launch screen popping up,
an error message was displayed:
"Please put the I Love Science! CD in a CD drive"
[Retry][Quit]
Clicking "Retry" will make the dialog disappear, then it appeared back almost
instantly. Clicking "Quit" will simply close the program.
I Love Science's CD was mounted at drive D:
Tested with WINE's Windows version 98.
I Love Science! is a Win16 application and supports Windows 3.x.
WINE: wine-1.5.6 source distribution.
System: Debian GNU/Linux 5.0 "Lenny" i386 (Intel Pentium 4 2.66GHz)
--
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=31418
Bug #: 31418
Summary: IE HTTPS Fails
Product: Wine
Version: 1.5.10
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fredrick.ward(a)gmail.com
Classification: Unclassified
Attempted install of IE8 under ubuntu 12.04. Pages open, but secure pages will.
Attempted to use wininet and winhttp respectively and neither resolved the
issue. install of crypt32 gets rid of error but then page cannot load
--
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=14055
Summary: Occasional wine crash during Heroes of Might and Magic
III gameplay
Product: Wine
Version: 1.0.0
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: riklaunim(a)gmail.com
Created an attachment (id=14275)
--> (http://bugs.winehq.org/attachment.cgi?id=14275)
Crash log
During gameplay the game may sometimes crash. It looks like the bug is related
to mp3/sound – “mp3dec.asi” (using OOS in wine). The log shows the
backtrace.
--
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.