[Bug 27901] New: Reproducible crash (and audio popping) in snd_pcm_area_copy [regression] [bisected]
http://bugs.winehq.org/show_bug.cgi?id=27901 Summary: Reproducible crash (and audio popping) in snd_pcm_area_copy [regression] [bisected] Product: Wine Version: 1.3.25 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs(a)winehq.org ReportedBy: bz-wine(a)kdzbn.homelinux.net CC: aeikum(a)codeweavers.com Created an attachment (id=35694) --> (http://bugs.winehq.org/attachment.cgi?id=35694) Failing test run, including stacktrace (FWIW I also hear this audio popping, and see this crash, in Unreal Gold, although that's going to be hard to find to test with. The crash goes away if I use directsound (presumably the non-directsound config uses winmm, though I don't know for sure; it's only UseDirectSound=True or False) in the Unreal config. But with directsound, I get no audio at all; I'll go debug that one next. Luckily, the same issues show up in the winmm tests.) The winmm regtest crashes ever since the mmdevapi rewrite change (either 901af51ea32f2d192a598808abab2d1b6a940773 or be158e48ad8ee556941bd3f1ff94ca7116680d00 was the change that caused the breakage to start; in between those two, the dlls/winmm/tests/wave.c test refuses to run). It also outputs a lot of audio popping before the crash in some modes, see below. This test runs several iterations of the 440Hz tone. The first (reference) tone runs fine. The CALLBACK_FUNCTION and CALLBACK_THREAD runs also work fine. Then the "10 headers" / CALLBACK_EVENT run is full of pops (approximately ten of them; looks like one per header). The "5 headers" / "1 loop" / CALLBACK_EVENT run is also full of pops, though I didn't count how many. (It's in the neighborhood of 10, though.) Then the 1-second 1-header test runs, with all three callback flags, and each run works fine (no popping). Then the 1-second 10-header CALLBACK_EVENT run starts; this one crashes almost immediately (though it does get a tiny bit of sound out the speaker first). The tests were all run like this, starting with the .wine-test2 directory not present: WINEPREFIX=$HOME/.wine-test2 WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c The full test log (from a git tree as of the 1.3.25 release) is attached, though note that I had to ctrl-c the test program at the end. I did let it run for a few minutes after the crash and before sending the ctrl-c, though. This system is LFS from a few years ago (and a couple local changes as well to get multilib). Versions of any package are available upon request, though everything is from source. Packages that I think are important: gcc-4.4.1 glibc-2.10.1 linux-2.6.39.3 (I have kept the kernel up to date) alsa-{lib,utils}-1.0.21 Sound device info (from "lspci -v", as root): 00:08.0 Multimedia audio controller: ALi Corporation M5455 PCI AC-Link Controller Audio Device (rev 20) Subsystem: ASRock Incorporation ASRock 939Dual-SATA2 Motherboard Flags: bus master, medium devsel, latency 96, IRQ 18 I/O ports at e800 [size=256] Memory at febff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0 (This is using ALSA, not OSSv4. "WINEPREFIX=$HOME/.wine-test2 ./wine winecfg" from the top-level directory shows that ALSA is the only system available; it's also selected.) The CPU is a dual-core Athlon64, and although the kernel was built in 64-bit mode and most of userspace is 64-bit, wine is built in 32-bit mode (USE_ARCH=32 CC="gcc -m32" CXX="g++ -m32" ./configure --prefix=/usr/local --disable-win64), and I have 32-bit versions of most libraries built and installed (which get activated based on a wrapper script around their xxxxxx-config scripts when present, and the USE_ARCH environment variable above). For any other system info that may be needed, just ask. -- 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=27901 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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=27901 --- Comment #1 from Andrew Eikum <aeikum(a)codeweavers.com> 2011-07-28 13:38:24 CDT --- Thanks for the detailed report. Could you give this another test with today's (or later) git? The important commit is 96aa86c99deeb12ff7c972370e2ca8fe4d1d8161. I don't know if this will change the situation, but it's worth a shot. I also noticed that your ALSA version is quite old, nearly two years. I'm not sure if that plays well with modern Wine or modern kernel. That might be worth upgrading to 1.0.24. -- 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=27901 Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #35694|0 |1 is obsolete| | --- Comment #2 from Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> 2011-07-29 00:26:16 CDT --- Created an attachment (id=35737) --> (http://bugs.winehq.org/attachment.cgi?id=35737) New test run -- 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=27901 --- Comment #3 from Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> 2011-07-29 00:36:15 CDT --- The crash is gone, as is some of the popping (at least during the first several tests). Unfortunately Unreal still crashes during the intro (unless I was using the wrong binary, which is entirely possible since I didn't install the compiled binary from the git tree, but rather tried running it directly from the tree). But let's get the test working first. But there's still a bit of popping. I've attached the most recent log. The popping starts after several of the "half second" delays (which go for much longer, and then fail the test), on the CALLBACK_EVENT|WAVE_FORMAT_DIRECT run with ten headers and zero loops. A couple of the other runs have the same behavior still. But it is a lot better. :-) (Device 0 and 1 are the same. Device 2 produces no sound at all, but that's unsurprising since it's the IEC device and I only use analog stereo sound. Device 3 is the mapper; I killed the test partway through that one.) I'll look into upgrading alsa as well, but that will have to be tomorrow (or later). -- 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=27901 --- Comment #4 from Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> 2011-07-30 21:12:48 CDT --- OK, I've upgraded alsa-lib and alsa-utils to the current versions. (1.0.24.1 and 1.0.24.2, respectively.) No change. I did manage to figure out why Unreal was crashing: the hardware acceleration setting was "full" by default. Given how many places explicitly said to set it to "emulation", I had assumed (yeah, I know) that "emulation" had become the default. (Also because many of those pages were pretty old.) It still pops relatively frequently in-game though. And that setting has no effect on the test run, either. -- 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=27901 --- Comment #5 from Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> 2011-08-06 22:32:44 CDT --- Synced to git head again (and noticed a couple of winmm changes that looked like they might have helped), but no luck. The test is still silent after the 0.5s sleep (if it's not just hung, though it doesn't look like it is). I added a few more trace lines to wave.c around the sleep test and to see if the WaitForSingleObject() call was actually working or not. I saw that the Sleep() call does indeed take about half a second, and the waveOutRestart() call doesn't hang either. But the sound does not restart after waveOutRestart(), and WaitForSingleObject times out after ten seconds. wave.c:729: Playing 1 second 440Hz tone at 8000x 8x1 1 header 0 loops 8000 bytes WAVE_FORMAT_PCM CALLBACK_EVENT wave.c:772: pausing for 0.5 seconds wave.c:774: sleep finished wave.c:776: waveOutRestart finished wave.c:792: Test failed: WaitForSingleObject(hevent) timed out wave.c:797: Test failed: (00) WHDR_DONE WHDR_PREPARED expected, got WHDR_INQUEUE WHDR_PREPARED wave.c:497: Test failed: waveOutGetPosition(0): returned 5298 bytes, should be 8000 wave.c:508: Test failed: waveOutGetPosition(0): returned 5298 samples (5298 bytes), should be 8000 (8000 bytes) wave.c:521: Test failed: waveOutGetPosition(0): returned 662 ms, (5296 bytes), should be 1000 (8000 bytes) wave.c:534: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:545: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:556: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:808: Test failed: waveOutUnprepareHeader(0): rc=WAVERR_STILLPLAYING(Cannot perform this operation while media data is still playing. Reset the device, or wait until the data is finished playing.) (The traces at line 774 and 776 are added by me, as is the test at line 792. So the subsequent line numbers are off by 3.) -- 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=27901 dura <newsgrp(a)duradsl.dyndns.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |newsgrp(a)duradsl.dyndns.org -- 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=27901 --- Comment #6 from dura <newsgrp(a)duradsl.dyndns.org> 2011-08-10 16:10:41 CDT --- The two commits (901af51ea32f2d192a598808abab2d1b6a940773 and be158e48ad8ee556941bd3f1ff94ca7116) are also causing audio popping in trackmania nation. To reproduce: simply start a track in solo mode and listen carefully. -- 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=27901 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Reproducible crash (and |Reproducible crash (and |audio popping) in |audio popping) in |snd_pcm_area_copy |snd_pcm_area_copy |[regression] [bisected] | -- 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=27901 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t --- Comment #7 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-09-23 16:34:39 CDT --- Bryan, this report is a bit confusing. It looks like the original crash is gone and the focus since shifted to winmm:wave tests failing. Please change the subject accordingly. I'd tend to confirm the test failure wave.c:794: Test failed: (00) WHDR_DONE WHDR_PREPARED expected, got WHDR_INQUEUE WHDR_PREPARED Wine's audio is sadly still somewhat fragile and too much dependent on settings that happen to work more or less well together, but beware of changing them in isolation (e.g. 100ms winmm buffer duration w.r.t. ALSA buffer size and timer callback rate, feeding silence w.r.t. underruns, using IAC_Stop w.r.t. GetPosition, using dmix or PulseAudio or raw hw:0). This is no good and we're slowly working on that... Don't hold your breath. Feel free to submit test results to test.winehq.org Meanwhile, I bet you get random hangs on the winmm:mci tests. I've one machine which does that in Ubuntu Intrepid with dmix. No failure with Pulseaudio, yet the bugs are all Wine's. In rare cases, the tests pass! As you already found out, waveOutRestart is involved, beside snd_pcm_drop and computations of GetPosition, with fluctuations depending on the time the periodic timers invoke the callbacks w.r.t. activity in other threads and period size vs. buffer sizes. Because PulseAudio, dmix and hw:0 use vastly different buffer sizes, they cause different "effects" in Wine. -- 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=27901 Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Reproducible crash (and |winmm tests timing out |audio popping) in |waiting for hevent after |snd_pcm_area_copy |waveOutRestart -- 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=27901 --- Comment #8 from Bryan Kadzban <bz-wine(a)kdzbn.homelinux.net> 2011-09-23 23:21:00 CDT --- Yeah, sorry about that. :-( The crash is fixed in almost all cases at least, and that was the biggest issue originally. Thanks! The issue that I was looking at was the popping (presumably a small underrun, though I don't know for sure) -- but the test hanging and failing is bad as well, I think. (I'm re-testing current git, since I got distracted for the last several weeks on other things. It does sound a lot better with respect to popping during the audio tests; I'll see if the popping is still happening in games as well. But it still hangs after pausing, never notifying the registered handle after the resume call goes through.) The mci test does ... well, something. :-) It doesn't yield any audio, and it does sometimes decide to hang (after the message "mci.c:1013: Test marked todo: mci status position: 2400", though I don't know which test it's running for sure). The output at the end (if it finishes) says 322 tests executed, 40 marked todo, 0 failures, 0 skipped. (There's another whole bug somewhere in here as well: alsa does not provide any indication of when a given sound sample has played, while OSS more or less does. This wouldn't be too bad, except that Red Alert 1 (the original) seems to use the mmapi equivalent 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 older version of Wine with the OSS driver. However that's not at *all* part of this bug report. I'm not even sure I'll make that one, actually.)
This is no good and we're slowly working on that... Don't hold your breath.
Yeah, it's probably not terribly easy, either. Thanks for the progress, though, at least! :-) -- 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=27901 --- Comment #9 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-09-24 16:55:01 CDT ---
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.
The issue that I was looking at was the popping Does bug #28284 offer any solution?
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
Red Alert 1 (the original) seems to use the mmapi equivalent What is mmapi? 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. 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.
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.
-- 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=27901 Raymond <superquad.vortex2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2(a)gmail.com --- Comment #10 from Raymond <superquad.vortex2(a)gmail.com> 2011-09-26 21:18:19 CDT --- (In reply to comment #9)
ALSA does not provide any indication of when a given sound sample has played, while OSS more or less does. Please elaborate.
some alsa driver only update hwptr on period bounadry only e.g. snd-ymfpci only update hwptr on 5.333 ms interval and you will need latest git of snd-usb-audio which update hwptr on 1 ms interval instead of 8 ms (playback) , capture is at 1 ms interval (1 urb) -- 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=27901 --- Comment #11 from Raymond <superquad.vortex2(a)gmail.com> 2011-09-30 01:08:27 CDT --- (In reply to comment #5)
Synced to git head again (and noticed a couple of winmm changes that looked like they might have helped), but no luck. The test is still silent after the 0.5s sleep (if it's not just hung, though it doesn't look like it is).
I added a few more trace lines to wave.c around the sleep test and to see if the WaitForSingleObject() call was actually working or not. I saw that the Sleep() call does indeed take about half a second, and the waveOutRestart() call doesn't hang either. But the sound does not restart after waveOutRestart(), and WaitForSingleObject times out after ten seconds.
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 you may use dmesg to check system log ALSA pcm_lib.c:1831: playback write error (DMA or IRQ trouble?) I also get the following error with the broken "au8830 wt" device 3 do the following error appear when using aplay ? aplay: pcm_write:1702: write error: Input/output error
wave.c:729: Playing 1 second 440Hz tone at 8000x 8x1 1 header 0 loops 8000 bytes WAVE_FORMAT_PCM CALLBACK_EVENT wave.c:772: pausing for 0.5 seconds wave.c:774: sleep finished wave.c:776: waveOutRestart finished wave.c:792: Test failed: WaitForSingleObject(hevent) timed out wave.c:797: Test failed: (00) WHDR_DONE WHDR_PREPARED expected, got WHDR_INQUEUE WHDR_PREPARED wave.c:497: Test failed: waveOutGetPosition(0): returned 5298 bytes, should be 8000 wave.c:508: Test failed: waveOutGetPosition(0): returned 5298 samples (5298 bytes), should be 8000 (8000 bytes) wave.c:521: Test failed: waveOutGetPosition(0): returned 662 ms, (5296 bytes), should be 1000 (8000 bytes) wave.c:534: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:545: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:556: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:808: Test failed: waveOutUnprepareHeader(0): rc=WAVERR_STILLPLAYING(Cannot perform this operation while media data is still playing. Reset the device, or wait until the data is finished playing.)
(The traces at line 774 and 776 are added by me, as is the test at line 792. So the subsequent line numbers are off by 3.)
-- 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=27901 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |901af51ea32f2d192a598808aba | |b2d1b6a940773 -- 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=27901 --- Comment #12 from Bryan Kadzban <bz-wine(a)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.
http://bugs.winehq.org/show_bug.cgi?id=27901 --- Comment #13 from Raymond <superquad.vortex2(a)gmail.com> 2011-10-09 03:24:39 CDT --- (In reply to comment #12)
(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).
actually it also fail with the same error wave.c:933: 1: "SB Live! Platinum [CT4760P] - M" (not supported) 256.1 (255:255) wave.c:936: channels=2 formats=fffff support=002c wave.c:938: WAVECAPS_VOLUME WAVECAPS_LRVOLUME WAVECAPS_SAMPLEACCURATE wave.c:730: Playing 1 second silence at 22050x 8x1 1 header 0 loops 22050 bytes WAVE_FORMAT_PCM CALLBACK_EVENT wave.c:730: Playing 1 second silence at 22050x 8x1 1 header 0 loops 22050 bytes WAVE_FORMAT_PCM CALLBACK_EVENT wave.c:773: pausing for 0.5 seconds wave.c:795: Test failed: (00) WHDR_DONE WHDR_PREPARED expected, got WHDR_INQUEUE WHDR_PREPARED wave.c:498: Test failed: waveOutGetPosition(1): returned 13523 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(1): returned 13523 samples (13523 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(1): returned 612 ms, (13516 bytes), should be 1000 (22050 bytes) -- 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=27901 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.4.0 --- Comment #14 from Austin English <austinenglish(a)gmail.com> 2011-10-09 15:22:09 CDT --- Sound bug => 1.4 milestone. -- 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=27901 --- Comment #15 from Raymond <superquad.vortex2(a)gmail.com> 2011-10-09 19:15:50 CDT --- it seem wine cannot work with 16 channels ./alsacap -d hw:0,3 *** Exploring configuration space of device `hw:0,3' for playback *** type : HW 16 channels Sampling rate 48000 Hz 48000 Sample formats: S16_LE Significant bits: 16 -- 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=27901 --- Comment #16 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-10-17 05:43:15 CDT ---
[...] this bug has been meandering quite a bit. The only issue remaining in the test [...] is the hang whenever the test pauses playback and tries to resume. That is the core of this bug, so it's not resolved yet. BTW, do you mean the mci or wave test?
-- 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=27901 --- Comment #17 from Raymond <superquad.vortex2(a)gmail.com> 2011-10-17 19:34:55 CDT --- wave.c:795: Test failed: (00) WHDR_DONE WHDR_PREPARED expected, got WHDR_INQUEUE WHDR_PREPARED It seem the above error with SB Live! device 3 (16 channels) was fixed by commit b0652dd8bdb144645be4a6bf77cbb68a8ade49d9 winealsa.drv: Don't try to control ALSA's behavior. -- 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=27901 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #18 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2012-01-18 16:57:55 CST --- I had hoped the "WHDR_DONE WHDR_PREPARED expected" issue had been entirely fixed by commit 77e01019c5ceb7fd2389764328a10903a99fb1c5 and earlier ones like commit 54b24f39260a3780bdf97d810a69647d7357cb62 In Ubuntu Intrepid the tests work well with both dmix and PulseAudio. The more recent Ubuntu Lucid is subject to the dreaded PulseAudio underrun bug while dmix works fine. Here's a log snippet which shows what happens with PA: AudioClock_GetPosition frames written: 22050, held: 0, avail: 882, delay: 636 state 3, pos: 21414 For 10 seconds, snd_pcm_avail and delay yield constant values. PA (or the ALSA plugin) missed an underrun, Wine never gets to see one. The stream position no more advances, it never reaches the end at 22050 and winmm waits in vain for its last packet. BTW: ALSA period: 220 frames playing 22050x8x1 ALSA buffer: 883 frames MMDevice period: 221 frames MMDevice buffer: 2205 frames Perhaps the PA situation will improve when we'll write trailing silence with bug #29299, but I don't know how yet to do that correctly, i.e. without causing adverse side effects to GetPosition etc. esp. if ALSA period > MMDevice period.
The only issue remaining in the test [...] is the hang whenever the test pauses playback and tries to resume. That is the core of this bug, so it's not resolved yet. Done now. Resume/Restart is definitively fixed by the above commit. We don't need this open here as a reminder that PA has bugs.
Bryan, if you still hear popping with 1.3.36/37, please enter another bug. -- 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=27901 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #19 from Alexandre Julliard <julliard(a)winehq.org> 2012-01-27 14:17:38 CST --- Closing bugs fixed in 1.4-rc1. -- 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.
participants (1)
-
wine-bugs＠winehq.org