http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #12 from Bryan Kadzban bz-wine@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?