http://bugs.winehq.org/show_bug.cgi?id=27937
Summary: winmm kept busy playing silence after play finishes Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: aeikum@codeweavers.com
The winmm player is kept busy for several seconds after audible rendering ends.
This is easily reproduced using my MCI shell from bug #20232, comment #10. Issue these commands to the MCI: open 8k8bitpcm.wav alias 8 ; any sample with at least 2 seconds of data play 8 from 1000 to 2000 notify ; play sample from position 1s to 2s play 8 from 1000 to 2000 WAIT status 8 mode I recommend to use a multi-line copy&paste to the console instead of typing.
The MCIWAVE player will correctly play 1 second worth of data. After that however, a random amount of upto 4 messages about ALSA pcm underrun are sent to the console, approx. 1 per second. It's only after those that the player eventually stops, i.e. execution of the synchronous command ends. The command "status 8 mode" serves to show when execution of the previous command ends.
I suspect the cause is the way mmdevapi handles silence and/or feeds too much data into the "default" ALSA device. I have no idea where that 1s log message spacing comes from.
Expected behaviour (as in 1.3.24): the synchronous (WAIT flag) player is kept busy for 1 second, after which the MCI shell processes the next command. Upto one ALSA pcm underrun log message is the norm, since indeed WINMM is closed only after all buffers (headers in waveOut* speak) have been returned to the app, i.e. there's a tiny gap between "played last header => Set Event" and waveOutClose. I.e. one underrun is designed into the WINMM API, after playing ends.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2011-08-05 04:20:23 CDT --- Created an attachment (id=35818) --> (http://bugs.winehq.org/attachment.cgi?id=35818) format + position + render tests
This is an update to attachment #35024 in bug #27393.
It's not yet ready for submission because of lack of complex todo_wine expressions, but it's slowly getting all the tests in that I want. It mostly passes on native in testbot job 13316.
It clearly shows: - native's IsFormatSupported - mmdevapi's GetPosition is not correct in Wine.
GetPosition is what's "currently playing through the speakers" http://www.winehq.org/pipermail/wine-devel/2011-August/091371.html
After playing for 1 second, GetPosition cannot be farther than nSamplesPerSec. The bug in Wine is that it's based on snd_pcm_avail_update, which is about buffer space, instead of snd_pcm_delay.
With dmix, it's funny that GetPosition is initially too far ahead but then calms down (see below). That's because there's no further buffering.
With PulseAudio, GetPosition yields values far away in the future. That alone explains why any app that tries to sync audio and video creates a huge lag. It's not the fault of PulseAudio.
Further bugs in Wine exhibited by the tests are: - Get/ReleaseBuffer OUT_OF_ORDER not correct yet; - ReleaseBuffer needs to check the size, otherwise it could overwrite memory! These should be fixed first before committing a test like mine because it requires convoluted if() todo_wine ok else ok to pass in Wine.
Surprisingly, the test seems to receive events even after Stop.
ALSA dmix output: render.c:745: Clock Frequency 48000 render.c:810: Test failed: Position 12473 too far after 100ms render.c:834: Test failed: Position 20665 too far after 200ms render.c:899: Test failed: Position 12721 too far after 100ms render.c:943: padding 902 position 21598 slept 450ms iteration 0 render.c:947: hpctime 451 pcpos 451 render.c:943: padding 18602 position 26398 slept 550ms iteration 1 render.c:947: hpctime 1251 pcpos 1251 render.c:996: position 83997 past underrun render.c:1006: hpctime 2251 after underrun
24000 samples after 0.5s play is ok.
ALSA Pulse output: render.c:810: Test failed: Position 24000 too far after 100ms render.c:831: Test failed: Position should have been further along... render.c:834: Test failed: Position 24000 too far after 200ms render.c:882: Test failed: Position 24000 too far after 100ms render.c:899: Test failed: Position 24000 too far after 100ms render.c:930: hpctime 353 after 350ms render.c:943: padding 0 position 22500 slept 450ms iteration 0 render.c:947: hpctime 454 pcpos 454 render.c:943: padding 0 position 45000 slept 550ms iteration 1 render.c:944: Test failed: Position 45000 too far after 550ms render.c:943: padding 0 position 67500 slept 650ms iteration 2 render.c:944: Test failed: Position 67500 too far after 650ms render.c:944: Test failed: Position 83898 too far after 750ms render.c:947: hpctime 1254 pcpos 1254 render.c:996: position 131844 past underrun render.c:1006: hpctime 2254 after underrun
PulseAudio's huge buffers eats a lot, but it cannot play faster than anybody else.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2011-08-07 01:27:01 CDT --- wine-1.3.26 The delay at the end is still present with ALSA (dmix) in Ubuntu Intrepid MacOS 10.5.8 is not affected.
W.r.t. GetPosition on MacOS: it looks good, except in the presence of an underrun: render.c:963: padding 20671 position 54563 slept 1250ms iteration 8 render.c:1007: position 54578 # rate is 44100 render.c:1017: position 98685 past underrun render.c:1019: Test failed: Position 98685 at end vs. 66150 played frames I'll have to open a separate issue about GetPosition after all.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #3 from Jörg Höhle hoehle@users.sourceforge.net 2011-08-10 11:39:07 CDT ---
I'll have to open a separate issue about GetPosition after all.
The MacOS issue about it is bug #28039, the ALSA one bug #28047. I have no idea whether they are the cause of the present issue with winmm.
http://bugs.winehq.org/show_bug.cgi?id=27937
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35818|0 |1 is obsolete| |
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2011-08-31 03:35:42 CDT --- Created an attachment (id=36171) --> (http://bugs.winehq.org/attachment.cgi?id=36171) mmdevapi/tests/render.c diff against wine-1.3.27
The rendering tests are now getting close to what I want for submission, except that - "exclusive mode disabled" has not been sufficiently tested; - WINETEST_DEBUG>1 causes GetPosition errors because the tests are so strict that sleep() is too unprecise. I need to use the PerfCounter to compute the position based on elapsed time instead of what I feed to sleep().
It passes on testbot and some native machines at normal debug settings, but will cause so many different todo_wine/"succeeded in todo_wine" errors in Wine depending on which of the 3 drivers is used and whether or not pulseaudio is used with ALSA that I don't know how to submit the tests prior to fixing more issues with the wine drivers. Using WINETEST_DEBUG is already a key to segregating tests that fail in Wine.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-19 09:41:31 CDT --- That bug is caused by waveform.c:WOD_PushData filling up the whole buffer with silence when the queue is empty. IMHO winmm has no business feeding that much silence. Something at most period_size should be the upper limit, if at all.
Feeding silence is strictly superfluous (once mmdevapi works correctly). I'm not convinced it helps in avoiding cracks at the end of a sound (IIRC MS recommends doing that) any better than simply entering an underrun. Why should it, what would be different?
I believe cracks are avoided by reducing volume or alternatively decreasing the sample value towards 0. Immediately writing 0 is asking for a crackling noise when the last sample value was e.g. 0.96.
Feeding silence is quite bad because it adds delays. What if the app submits data 0.5ms after winmm decided to write some silence? Suddenly pauses will be heard where there should be none.
See bug #28027 for another issue caused by writing silence.
http://bugs.winehq.org/show_bug.cgi?id=27937
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #6 from Erich Hoover ehoover@mines.edu 2011-09-22 09:07:05 CDT --- (In reply to comment #5)
Feeding silence is strictly superfluous (once mmdevapi works correctly). I'm not convinced it helps in avoiding cracks at the end of a sound (IIRC MS recommends doing that) any better than simply entering an underrun. Why should it, what would be different?
In commit 64b14c0ecdd13530a92ff636c451523a99253a0b Maarten Lankhorst suggests that it fixes the audio glitching when the audio starts back up again. Note that I'm not an expert in the topic, I'm just aware of it because that commit has been a "pain in the mitka" when it comes to using the Fallout games with PulseAudio.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #7 from Raymond superquad.vortex2@gmail.com 2011-09-24 18:28:18 CDT --- Created attachment 36537 --> http://bugs.winehq.org/attachment.cgi?id=36537 Test playback/capture position
(In reply to comment #1)
After playing for 1 second, GetPosition cannot be farther than nSamplesPerSec. The bug in Wine is that it's based on snd_pcm_avail_update, which is about buffer space, instead of snd_pcm_delay.
With dmix, it's funny that GetPosition is initially too far ahead but then calms down (see below). That's because there's no further buffering.
With PulseAudio, GetPosition yields values far away in the future. That alone explains why any app that tries to sync audio and video creates a huge lag. It's not the fault of PulseAudio.
pulse plugin seem only update pointer at the selected period time.
so the playback/capture position is less inaccurate than those plug:dmix or hw for hda-intel
you can use the attach program to print the playback/capture position of different device (e.g. hw, plug:dmix, pulse, plughw, plug:jack)
alsa_test device dir rate periods stop_at_underrun silence
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-26 14:44:57 CDT --- The "don't write silence" patch to mmdevapi is at http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html for everybody to try out. I've judged that it's too early for inclusion into Wine now because of some other bugs, but you may want to find out what apps are helped by it.
http://bugs.winehq.org/show_bug.cgi?id=27937
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl 2011-10-08 09:36:50 CDT --- (In reply to comment #8) I've briefly tested this patch against 1.3.29 (as yesterday there was no release, so it's still without all the recent gutting changes).
I've got pulseaudio 1.0 and alsa-plugins 1.0.24 with those two git underrun patches.
The patch created a minor improvement in that brief test. I tested with a game that uses midi and wave at the same time.
Without the patch, midi parts were playing fine, but the wave parts sometimes didn't start and stayed that way till exiting the game (so, probably, it was just playing silence for the rest of the time).
With this patch, the sound seems to start properly every time, though sometimes when skipping through cutscenes it stutters a bit, as if it was played a tad too slow.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #10 from Rafał Mużyło galtgendo@o2.pl 2011-10-08 20:57:44 CDT --- Sorry, I spoke too soon - the silencing still happens with 'err:alsa:wine_snd_pcm_recover underrun occurred'.
But till the next release, no valid results can be acquired anyway.
http://bugs.winehq.org/show_bug.cgi?id=27937
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.4.0
--- Comment #11 from Austin English austinenglish@gmail.com 2011-10-09 15:22:48 CDT --- Sound bug => 1.4 milestone.
http://bugs.winehq.org/show_bug.cgi?id=27937
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #12 from Alexey Loukianov mooroon2@mail.ru 2011-10-18 18:21:36 CDT --- FYI: I had tried your patch from http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html in order to check if it "heals" recently introduced regression reported in bug #28723. I neither helps nor breaks anything.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #13 from Andrew Eikum aeikum@codeweavers.com 2011-10-28 09:49:27 CDT --- (In reply to comment #8)
The "don't write silence" patch to mmdevapi is at http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html for everybody to try out. I've judged that it's too early for inclusion into Wine now because of some other bugs, but you may want to find out what apps are helped by it.
I think it's safe to resend this now.
http://bugs.winehq.org/show_bug.cgi?id=27937
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1cde966c35dcb0b5dc7bc5a6c42 | |b788f6d8f561c Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #14 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-03 08:08:42 CDT --- Fixed by http://source.winehq.org/git/wine.git/commit/1cde966c35dcb0b5dc7bc5a6c42b788... winmm is no more writing silence.
Rafał, open a distinct bug if stuttering persists with your app.
http://bugs.winehq.org/show_bug.cgi?id=27937
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2011-11-04 14:14:19 CDT --- Closing bugs fixed in 1.3.32.
http://bugs.winehq.org/show_bug.cgi?id=27937
--- Comment #16 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-22 04:42:27 CST ---
I think it's safe to resend this now.
Maybe it was too early after all. I didn't perform the regression test, but MacOS presents many winmm:wave failures now. test.winehq shows failures appeared between 2010-10-27 and 2011-11-01 (commits fe1f692d9149 upto 3f74c581b818) and that was the only relevant change. I'm sorry I missed that before submitting. Hopefully MacOS behaviour will be fixed with bug #28039.
http://bugs.winehq.org/show_bug.cgi?id=27937
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36171|0 |1 is obsolete| |
--- Comment #17 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-22 09:52:22 CST --- Created attachment 38073 --> http://bugs.winehq.org/attachment.cgi?id=38073 mmdevapi/tests/render.c diff against wine-1.3.35 (or 34/33/...)
This is an update reflecting current knowledge about mmdevapi.
Additional tests are performed using set WINETEST_DEBUG=2 or 3 in a DOS shell
Running with output redirected to a >file.txt is recommended on native, because the DOS shell slows down output EXTREMEly, yielding to several errors from GetPosition. E.g. each renderer iteration normally takes 100ms, with console output it can be twice as much.
http://bugs.winehq.org/show_bug.cgi?id=27937
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38073|0 |1 is obsolete| |
--- Comment #18 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-25 07:11:25 CST --- Created attachment 38547 --> http://bugs.winehq.org/attachment.cgi?id=38547 mmdevapi/tests/render.c diff against wine-1.3.37
I've added an XAudio/Rage bug #28723 worst-case underrun style scenario. Ideally, I should add some sine or saw tooth to produce noise!
http://bugs.winehq.org/show_bug.cgi?id=27937
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38547|0 |1 is obsolete| |
--- Comment #19 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-02 16:34:18 CST --- Created attachment 38670 --> http://bugs.winehq.org/attachment.cgi?id=38670 mmdevapi/tests/render diff against wine-1.4-rc2
Added sine output. Use with WINETEST_INTERACTIVE=1 or runtest -i
Good at detecting whether your audio environment would bear XAudio2 output or stutter, see bug #28723.
-
wine-bugs＠winehq.org