[Bug 27901] winmm tests timing out waiting for hevent after waveOutRestart

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Oct 8 23:47:33 CDT 2011


http://bugs.winehq.org/show_bug.cgi?id=27901

--- Comment #12 from Bryan Kadzban <bz-wine at kdzbn.homelinux.net> 2011-10-08 23:47:33 CDT ---
(Sorry, was out for quite a while.  :-/ )

(In reply to comment #9)
> >The mci test does ... well, something.  
> 
> If you plug a microphone you should hear yourself.
> Use WINEDEBUG=+winmm and you'll see it hangs after waveOutRestart.

Ah.  No mic to test this one.

The last time this test hung (with WINEDEBUG=+winmm), the test was logging
"WOD_PushData (0xc000)" repeatedly, and the only stuff related to waveOutPause
/ waveOutRestart seems to be before that loop starts:

trace:winmm:WINMM_BeginPlaying (0xc000)
trace:winmm:WOD_PushData (0xc000)
mci.c:1074: Test marked todo: mci pause (space) wait returned
MCIERR_EXTENSION_NOT_FOUND
trace:winmm:waveOutPause (0xc000)
trace:winmm:WINMM_Pause (0xc000)
trace:winmm:WOD_PushData (0xc000)
trace:winmm:waveOutWrite (0xc000, 0x12d520, 32)
mci.c:1085: position after resume: 333ms
trace:winmm:waveOutReset (0xc000)
trace:winmm:WINMM_Reset (0xc000)
trace:winmm:WINMM_Pause (0xc000)
trace:winmm:WINMM_BeginPlaying (0xc000)
trace:winmm:WOD_PushData (0xc000)

(The last line just repeats.)  Looks odd that waveOutPause was called before
waveOutWrite/waveOutReset, and WINMM_Pause was called just before
WINMM_BeginPlaying.  But I have no idea what any of these functions are
supposed to do, either.

If you want, I can generate a full +winmm log (say, from a hanging and a
successful mci.c run) and attach it?

> >The issue that I was looking at was the popping
> 
> Does bug #28284 offer any solution?

Well, it isn't happening anymore.  Based on the times I was able to run tests,
and the versions I was using, I am *guessing* that one of the patches to git
from that bug was responsible for the fix of the popping.  But even if not --
thanks!  :-)

The only issue remaining in the test (with git as of the last update I provided
here, as well as with current git) is the hang whenever the test pauses
playback and tries to resume.

> >ALSA does not provide any indication of when a given
> >sound sample has played, while OSS more or less does.
>
> Please elaborate.
> 
> If you have OSS4, you may wish to contribute to bug #28056

I don't, though I wonder if it would make any difference.  Hmm.

As for the comment above this, it might be that I'm wrong, but I was under the
impression that OSS (v3), since it was closer to the sound hardware, was able
to provide better indications of when sounds actually played than ALSA was. 
And I am pretty sure that Red Alert uses some kind of notification from winmm
as a fixed wall-clock-time notification stream, to sync its video.

So I *think* that these, together, mean that when no sound is playing, the
notifications are coming in at the wrong times, making the video play extremely
fast.  But it may not be because ALSA is so far up from the hardware, or due to
the design of ALSA itself, at all.  I could be totally wrong on the cause; I
don't know the APIs well enough to know what's happening.

> >Red Alert 1 (the original) seems to use the mmapi equivalent
> 
>   What is mmapi?

Oops, too many acronyms.  :-(  I meant winmm there; see above.

> >notifications to control the rate that its video runs at.  The videos
> >run with no sound and at an extremely fast framerate, unless I use an
> 
>   A huge framerate is symptomatic of loss of sync in absence of sound.

Yeah, that was my assumption.

> >older version of Wine with the OSS driver.
> 
> For developers, a regression is generally easier to debug than when something
> never ever worked. So working sync with old OSS is a good starting point.

Well, it never worked with ALSA, but did with OSS (v3), before the sound system
rewrite that removed the OSSv3 driver.  Not sure if that helps at all.  :-)

> >However that's not at *all* part of this bug report.  I'm not even
> >sure I'll make that one, actually.
> 
> You should create a new bug report.  I want Wine to provide correct audio
> position information such that video and lip syncing works. I'm happy when
> people exhibit apps that do depend on that and test them.

Eventually; let's see if I can keep stuff happening in sequence, rather than
getting myself confused in parallel.  :-)

Luckily, it's a free download (after EA tried to use it to promote RA3), though
the ISOs are pretty large.

(In reply to comment #11)
> It seem that your alsa device is broken if it is after ten seconds
> since alsa has a timeout of 10 seconds when the sound card's interrupt fail

Possibly, though it works with everything else?  Still, looking...

> you may use dmesg to check system log
> 
> ALSA pcm_lib.c:1831: playback write error (DMA or IRQ trouble?)

The kernel does not log anything when this happens.  Neither do other userspace
programs (not that they would, but still; nothing in any of the syslogd-written
log files).

> do the following error appear when using aplay ?
> 
> aplay: pcm_write:1702: write error: Input/output error

Nope, aplay works fine.  (At least on the first .wav file I found laying
around.)  So do other alsa programs (e.g. audacious2), including their
pause/resume controls.  Though I don't know what they're doing in terms of ALSA
API calls; maybe that isn't comparable.

Anyway, this bug has been meandering quite a bit.  I wouldn't mind calling it
RESOLVED (since sound appears to work in the vast majority of cases for the
games I run under wine, anyway, even if the test is doing weird things), unless
there's a good reason not to?

-- 
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.



More information about the wine-bugs mailing list