[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@winehq.org ReportedBy: bz-wine@kdzbn.homelinux.net CC: aeikum@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #1 from Andrew Eikum aeikum@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Bryan Kadzban bz-wine@kdzbn.homelinux.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35694|0 |1 is obsolete| |
--- Comment #2 from Bryan Kadzban bz-wine@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
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #3 from Bryan Kadzban bz-wine@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).
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #4 from Bryan Kadzban bz-wine@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #5 from Bryan Kadzban bz-wine@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.)
http://bugs.winehq.org/show_bug.cgi?id=27901
dura newsgrp@duradsl.dyndns.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |newsgrp@duradsl.dyndns.org
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #6 from dura newsgrp@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Dmitry Timoshkov dmitry@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] |
http://bugs.winehq.org/show_bug.cgi?id=27901
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #7 from Jörg Höhle hoehle@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Bryan Kadzban bz-wine@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
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #8 from Bryan Kadzban bz-wine@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! :-)
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #9 from Jörg Höhle hoehle@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Raymond superquad.vortex2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2@gmail.com
--- Comment #10 from Raymond superquad.vortex2@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)
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #11 from Raymond superquad.vortex2@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.)
http://bugs.winehq.org/show_bug.cgi?id=27901
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |901af51ea32f2d192a598808aba | |b2d1b6a940773
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?
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #13 from Raymond superquad.vortex2@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)
http://bugs.winehq.org/show_bug.cgi?id=27901
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.4.0
--- Comment #14 from Austin English austinenglish@gmail.com 2011-10-09 15:22:09 CDT --- Sound bug => 1.4 milestone.
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #15 from Raymond superquad.vortex2@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
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #16 from Jörg Höhle hoehle@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?
http://bugs.winehq.org/show_bug.cgi?id=27901
--- Comment #17 from Raymond superquad.vortex2@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #18 from Jörg Höhle hoehle@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.
http://bugs.winehq.org/show_bug.cgi?id=27901
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2012-01-27 14:17:38 CST --- Closing bugs fixed in 1.4-rc1.
-
wine-bugs＠winehq.org