http://bugs.winehq.org/show_bug.cgi?id=28622
Bug #: 28622 Summary: alsa under pulseaudio no longer produce sound. Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs@winehq.org ReportedBy: gilboad@gmail.com Classification: Unclassified
Created attachment 36780 --> http://bugs.winehq.org/attachment.cgi?id=36780 WINEDEBUG=+tid,+mmdevapi,+winmm,+dsound,+oss,+alsa,+coreaudio wine vlc.exe
Since the introduction of the new mmdevapi layer, wine / Fedora 15/x86_64 no longer reliably produces sound. winecfg sound test does produce badly distorted sound, but that's vlc under a newly created prefix produces a single note and then dies.
Generate configuration. Fedora 15, x86_64 running on dual Xeon workstation w/ SB Audigy 2SZ card. wine 1.3.29 from updates-testing.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|mmdevapi |-unknown Version|unspecified |1.3.29
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #1 from Gilboa Davara gilboad@gmail.com 2011-10-09 00:26:55 CDT --- P.S. Fedora uses PA 0.9.22 and alsa 1.0.24.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=28622
Raymond superquad.vortex2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2@gmail.com
--- Comment #2 from Raymond superquad.vortex2@gmail.com 2011-10-12 04:37:19 CDT --- reduce the period time from 200 *10000 to 2321930 (23.2ms) in dlls/dsound/primary.c seem fix the choppy sound
200ms @44100Hz is too large (> half buffer size when your sound card only have 64K Bytes buffer 371ms)
/* buffer size = 200 * 100000 (100 ns) = 2.0 secods */ hres = IAudioClient_Initialize(device->client, AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_NOPERSIST, - 200 * 100000, 50000, device->pwfx, NULL); + 2321930, 50000, device->pwfx, NULL);
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #3 from Andrew Eikum aeikum@codeweavers.com 2011-10-12 13:02:16 CDT --- Created attachment 36857 --> http://bugs.winehq.org/attachment.cgi?id=36857 dsound: Request a more exact buffer size from MMDevAPI
(In reply to comment #2)
reduce the period time from 200 *10000 to 2321930 (23.2ms) in dlls/dsound/primary.c seem fix the choppy sound
200ms @44100Hz is too large (> half buffer size when your sound card only have 64K Bytes buffer 371ms)
/* buffer size = 200 * 100000 (100 ns) = 2.0 secods */ hres = IAudioClient_Initialize(device->client, AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_NOPERSIST,
200 * 100000, 50000, device->pwfx, NULL);
2321930, 50000, device->pwfx, NULL);
That's the buffer size, not the period size. In any case, I have this patch in my queue which does the same thing a little more intelligently. It requests the buffer size to be exactly as large as the maximum data that dsound will send to mmdevapi. I've attached it here, and it fixes VLC for me as well.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #4 from Raymond superquad.vortex2@gmail.com 2011-10-13 21:04:22 CDT --- (In reply to comment #3)
Created attachment 36857 [details] dsound: Request a more exact buffer size from MMDevAPI
(In reply to comment #2)
reduce the period time from 200 *10000 to 2321930 (23.2ms) in dlls/dsound/primary.c seem fix the choppy sound
200ms @44100Hz is too large (> half buffer size when your sound card only have 64K Bytes buffer 371ms)
/* buffer size = 200 * 100000 (100 ns) = 2.0 secods */ hres = IAudioClient_Initialize(device->client, AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_NOPERSIST,
200 * 100000, 50000, device->pwfx, NULL);
2321930, 50000, device->pwfx, NULL);That's the buffer size, not the period size. In any case, I have this patch in my queue which does the same thing a little more intelligently. It requests the buffer size to be exactly as large as the maximum data that dsound will send to mmdevapi. I've attached it here, and it fixes VLC for me as well.
it is period time in alsa driver , choppy sound because wine is using 1 period per buffer on SB Live! Platinum (8820 frames 0.2 second period time)
The other point is you have removed the difference between primary/secondary buffer , vlc is trying to change the primary buffer format
trace:dsound:DirectSoundDevice_SetCooperativeLevel (0x182f190,0x10040,DSSCL_EXCLUSIVE) warn:dsound:DirectSoundDevice_SetCooperativeLevel level=DSSCL_EXCLUSIVE not fully supported
Since vlc support both winmm and dsound output module , playing a 22050Hz wav with SB Live! Platinum
winealsa(winmm) use 22050Hz (221 frames 10.022ms)
winealsa(dsound) resample to 44100Hz (ds_default_sample_Rate) (512 frames 11.609ms)
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #5 from Gilboa Davara gilboad@gmail.com 2011-10-22 01:13:19 CDT --- Do you want me to test one of the patches?
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #6 from Andrew Eikum aeikum@codeweavers.com 2011-10-24 08:12:59 CDT --- Gilboa: Have you upgraded to Wine 1.3.31 and retested your audio? All of my important audio patches are in 1.3.31. If it still isn't working, can you please run winecfg's Test Sound and attach another log with the channels listed at http://wiki.winehq.org/Sound?
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #7 from Gilboa Davara gilboad@gmail.com 2011-11-01 01:46:01 CDT --- I've built .31 and it does produce somewhat distorted sound, but the performance hit is pretty major. I've installed Fedora Pulse-fied .18 (The only thing readily available for me) and I get perfect sound and far, far better performance when sound effects are active. Here I need guidance: should I open a separate bug report about this (regression? mmdevapi rewrite? DX regression?) or would you rather track this issue in this bug report?
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #8 from Andrew Eikum aeikum@codeweavers.com 2011-11-01 10:35:43 CDT --- (In reply to comment #7)
I've built .31 and it does produce somewhat distorted sound, but the performance hit is pretty major. I've installed Fedora Pulse-fied .18 (The only thing readily available for me) and I get perfect sound and far, far better performance when sound effects are active. Here I need guidance: should I open a separate bug report about this (regression? mmdevapi rewrite? DX regression?) or would you rather track this issue in this bug report?
No, let's stick with this bug. Gathering that log from 1.3.31 or later is the best next step.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #9 from Gilboa Davara gilboad@gmail.com 2011-11-13 11:46:52 CST --- Created attachment 37482 --> http://bugs.winehq.org/attachment.cgi?id=37482 WINEDEBUG=+tid,+mmdevapi,+winmm,+dsound,+oss,+alsa,+coreaudio wine vlc.exe (1.3.32)
http://bugs.winehq.org/show_bug.cgi?id=28622
Gilboa Davara gilboad@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.3.29 |1.4-rc4 Summary|alsa under pulseaudio no |vlc |longer produce sound. |(alsa-plugin/pulseaudio) | |produces highly distorted | |sound.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #10 from Gilboa Davara gilboad@gmail.com 2012-02-24 03:36:38 CST --- Created attachment 39038 --> http://bugs.winehq.org/attachment.cgi?id=39038 WINEDEBUG=+tid,+mmdevapi,+winmm,+dsound,+oss,+alsa,+coreaudio wine vlc.exe c:\KDE_Startup_new.wav (1.4.0rc4)
How can I help you fix this issue?
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.4-rc4 |1.3.29 Summary|vlc |alsa under pulseaudio no |(alsa-plugin/pulseaudio) |longer produce sound |produces highly distorted | |sound. |
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru 2012-02-24 05:09:33 CST --- No sound and distorted sound are 2 different issues, open a separate bug report for that.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #12 from Andrew Eikum aeikum@codeweavers.com 2012-02-24 07:43:19 CST --- Gilboa, are you still running PA 0.9.22 and alsa-plugins 1.0.24?
It seems that this problem is fixed with later PA and alsa-plugins versions. Please see the entry in http://wiki.winehq.org/Sound.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #13 from Gilboa Davara gilboad@gmail.com 2012-02-24 08:07:39 CST --- (In reply to comment #12)
Gilboa, are you still running PA 0.9.22 and alsa-plugins 1.0.24?
It seems that this problem is fixed with later PA and alsa-plugins versions. Please see the entry in http://wiki.winehq.org/Sound.
Nope. I'm using PA 0.9.23 and alsa 1.0.25. -- alsa-lib-1.0.25-1.fc16.i686 alsa-lib-1.0.25-1.fc16.x86_64 pulseaudio-libs-0.9.23-1.fc16.i686 pulseaudio-libs-0.9.23-1.fc16.x86_64
As far as I know, this should be a safe combination, right? Do you want me to create a new clean prefix, install VLC 2 and retest?
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #14 from Gilboa Davara gilboad@gmail.com 2012-02-24 08:10:04 CST --- Dmitry,
I am getting sound, but highly distorted one. I asked if I should open a new bug report, and Andrew (comment #8) advised me to continue in this one.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru 2012-02-24 08:19:39 CST --- (In reply to comment #14)
I am getting sound, but highly distorted one. I asked if I should open a new bug report, and Andrew (comment #8) advised me to continue in this one.
If Andrew wants to continue gathering data from this bug report that's fine with me. But a common agreement is a separate bug report for each separate issue, especially since the original problem has been fixed it seems.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #16 from Gilboa Davara gilboad@gmail.com 2012-02-25 03:12:15 CST --- Andrew,
Do you want me to close this bug and open a new one (vlc / pulse produces distorted sound) or do you want to continue using this bz# and rename it? Either option is fine by me.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #17 from Dmitry Timoshkov dmitry@baikal.ru 2012-02-25 03:28:18 CST --- (In reply to comment #16)
Do you want me to close this bug and open a new one (vlc / pulse produces distorted sound) or do you want to continue using this bz# and rename it? Either option is fine by me.
Please don't change the subject and/or originally reported Wine version, they should match an originally reported problem/configuration. Reusing bugs just adds more confusion, and is discouraged.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #18 from Andrew Eikum aeikum@codeweavers.com 2012-02-27 07:37:45 CST --- It really doesn't matter to me. I think of this bug as "sound works poorly on Gilboa's fedora 15 machine with PA 0.9.23 and alsa-plugins 1.0.25". Whatever bug number it has is irrelevant.
Gilboa, is upgrading to PulseAudio >= 1.1 an option? I'm not familiar with Fedora's packaging system. I've found that most people report success with PA 1.1, alsa-plugins 1.0.25, and Wine 1.4-rc1 or later.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #19 from Gilboa Davara gilboad@gmail.com 2012-02-27 08:02:04 CST --- I'm currently on Fedora 16. I'm trying to rebuild the F17/alpha pulseaudio v1.1 and report my findings.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #20 from Gilboa Davara gilboad@gmail.com 2012-02-29 00:31:17 CST --- Sadly enough, no go; If anything sound is more distorted that it used to be :(
$ rpm -qa | egrep -e 'pulseaudio-libs|alsa-plugins-pulse' | sort alsa-plugins-pulseaudio-1.0.25-3.fc16.i686 alsa-plugins-pulseaudio-1.0.25-3.fc16.x86_64 pulseaudio-libs-1.1-3.fc16.i686 pulseaudio-libs-1.1-3.fc16.x86_64 pulseaudio-libs-devel-1.1-3.fc16.x86_64 pulseaudio-libs-glib2-1.1-3.fc16.x86_64
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #21 from Gilboa Davara gilboad@gmail.com 2012-02-29 00:47:52 CST --- I removed the prefix and created a new one. Within winecfg, when I press "test sound", I get highly distorted sound and the console is full of "ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred" errors. Outside of wine, sound works perfectly under both multimedia applications and SDL and openal games.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #22 from Andrew Eikum aeikum@codeweavers.com 2012-03-01 08:50:45 CST --- Thanks for trying, Gilboa. If you still have those versions installed, can you throw me another log? You're one of the first people I've seen with up-to-date PulseAudio still having problems.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #23 from Gilboa Davara gilboad@gmail.com 2012-03-01 12:23:59 CST --- Created attachment 39146 --> http://bugs.winehq.org/attachment.cgi?id=39146 winecfg sound test log (wine-1.4-0.7.rc5, PA 1.1)
Attached.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #24 from Raymond superquad.vortex2@gmail.com 2012-03-02 02:33:56 CST --- it seem that "default" output module in vlc 2.0.0 prefence does not produce any sound like vlc 1.1.11 , the other output module "dsound" and "win32 waveout" modules still work
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #25 from Gilboa Davara gilboad@gmail.com 2012-03-02 02:59:29 CST --- ... I'll give it a try. But the I'm getting highly distorted sound using winecfg's build in sound tester....
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #26 from Gilboa Davara gilboad@gmail.com 2012-03-02 03:03:14 CST --- ... Just tested waveout and dsound under VLC 2.0 - Same results.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t Component|-unknown |winealsa.drv
--- Comment #27 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-03 02:31:46 CST --- Am I wrong or is Fedora involved with every PulseAudio bug in Wine, e.g. bug #28856? Maybe it's time for a bug in their bugtracker?
AUDDRV_GetAudioEndpoint Opening PCM device "default" with handle_underrun: 0
That line proves PulseAudio is being used. Let's have a look.
AudioClient_Initialize ALSA period: 441 frames AudioClient_Initialize ALSA buffer: 1764 frames AudioClient_Initialize MMDevice period: 441 frames AudioClient_Initialize MMDevice buffer: 4410 frames
Quite normal.
AudioClient_Start (0x147528) AudioClock_GetPosition frames written: 4410, held: 4410, avail: 1764, delay: 0 state 2, pos: 0 AudioClock_GetPosition frames written: 4410, held: 3087, avail: -32, delay: 1321 state 4, pos: 1323
That's the point where experience with other bug reports tells to restart the PA server. Why does even the first write (of 30ms, 1323=3*441 frames) result in a underrun (EPIPE=-32)?
The underrun makes winealsa believe that all written frames were played, raising position to 1323. This is different from the following well-known transient error where PA returns EIO=-5 when too little time has elapsed after the initial write, so winealsa keeps the position as is:
AudioClock_GetPosition frames written: 24534, held: 0, avail: 1763, delay: 1057 state 3, pos: 23814 alsa_write_data XRun state avail -32, recovering AudioClock_GetPosition snd_pcm_delay failed in state 2: -5 (Input/output error) AudioClock_GetPosition frames written: 24534, held: 0, avail: 1764, delay: xx state 2, pos: 23814
If you wade through the log where winmm was used 3x to play a ~1/2 second sound, you'll see that winealsa almost constantly got avail: -32. IOW, winealsa played nothing. There are rare exceptions:
AudioClock_GetPosition frames written: 24534, held: 0, avail: 1763, delay: 1057 state 3, pos: 23814
Even that looks strange. Why is avail 1763 and not the full buffer size 1764? This is an off by one thing that I've observed with my ancient 0.9.x PA from Ubuntu Intrepid already. Perhaps resampling and rounding constraints in PA can explain it?
So normally, I'd dismiss such a situation as yet another PulseAudio bug. However:
Outside of wine, sound works perfectly under both multimedia applications and SDL and openal games.
I fail to see what Wine does wrong. One last idea: In dlls/winealsa.drv/mmdevdrv.c:alsa_enum_devices, please comment out the for loop involving snd_card_next. Then only "default" (if you added nothing via the registry), no "plughw:N.N" will be acccessed. Does that change anything?
Also, may I suggest as work-around to use winecfg to have winealsa use the low-level "SB Audigy 2 ZS" or "HDA Intel" for output? This may prevent other apps from doing output concurrently, but might give you working sound in Wine.
If you need to post another log, I recommend our render tests: cd dlls/mmdevapi/tests; rm /tmp/render.log WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi wine mmdevapi_test.exe.so render >>/tmp/render.log 2>&1 with winecfg or the registry set your preferred device (if not "default").
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #28 from Rosanne DiMesio dimesio@earthlink.net 2012-03-03 13:22:58 CST --- (In reply to comment #27)
Am I wrong or is Fedora involved with every PulseAudio bug in Wine, e.g. bug #28856? Maybe it's time for a bug in their bugtracker?
Bug 27895 seems to be mostly Ubuntu, but also has comments from Mint and Gentoo users. While most of the users there are using older PA/ALSA-plugin versions, at least one Ubuntu 12.04 user reported problems with PA 1.1 and libasound2 1.0.25.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #29 from Raymond superquad.vortex2@gmail.com 2012-03-03 17:32:47 CST --- does pulseaudio respawn when there is audio stream playing with audigy 2 ?
or anyone with snd-hda-intel which support independent headphone
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/module-...
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #30 from Gilboa Davara gilboad@gmail.com 2012-03-04 05:34:51 CST --- (In reply to comment #27)
Am I wrong or is Fedora involved with every PulseAudio bug in Wine, e.g. bug #28856? Maybe it's time for a bug in their bugtracker?
In previous releases (when Fedora carried winepulse) this bug would have landed solely in Fedora bugzilla. However, given the fact the bug *only* gets triggered by wine (other alsa-pulse applications such as flash-plugin do not exhibit this) and given the fact that as far as I can see, Fedora uses more-or-less stock wine, I rather try here first.
That's the point where experience with other bug reports tells to restart the PA server. Why does even the first write (of 30ms, 1323=3*441 frames) result in a underrun (EPIPE=-32)?
I restarted PA manually on two machines, one of Intel-HDA and the other with Audigy 2, tried VLC and got the same results. Just to verify that PA is indeed working, I played a short springrts game (oh, life is indeed tough :)), and played a short flash video (non-HTML5).
I fail to see what Wine does wrong. One last idea: In dlls/winealsa.drv/mmdevdrv.c:alsa_enum_devices, please comment out the for loop involving snd_card_next. Then only "default" (if you added nothing via the registry), no "plughw:N.N" will be acccessed. Does that change anything?
Tried using winecfg to select another device (instead of default) - no go.
Also, may I suggest as work-around to use winecfg to have winealsa use the low-level "SB Audigy 2 ZS" or "HDA Intel" for output? This may prevent other apps from doing output concurrently, but might give you working sound in Wine.
... Please, please, please don't break pulse.
If you need to post another log, I recommend our render tests: cd dlls/mmdevapi/tests; rm /tmp/render.log WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi wine mmdevapi_test.exe.so render >>/tmp/render.log 2>&1 with winecfg or the registry set your preferred device (if not "default").
Attached.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #31 from Gilboa Davara gilboad@gmail.com 2012-03-04 05:36:32 CST --- Created attachment 39184 --> http://bugs.winehq.org/attachment.cgi?id=39184 mmdevapi test results (Intel-HDA, default PA)
(I'll update second render log w/ PA 1.1 and Audigy 2 later today).
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #32 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-04 15:10:43 CST ---
Tried using winecfg to select another device (instead of default) - no go.
If we want to make progress, you must be very precise. What does no go mean? No sound at all from any device? Did the AUDDRV_GetAudioEndpoint line in a WINEDEBUG=+alsa log show that the requested device was opened successfully?
I'll update second render log w/ PA 1.1 and Audigy 2 later today.
Ok, but what did you hear from the render test? Occasional crackling? Continuous crackling? No sound at all?
Please, please, please don't break pulse.
It is not our intent at all. I've spent hours, evenings, week-ends and nights trying to figure out a way to make PA produce sound reliably. I failed. Even simplest programs (without Wine) managed to see the PA server lose its ability to play any sound from any program. Here's one bug I posted to PA's bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46296 PA is one of the reasons that I'm still using the now unsupported Ubuntu Intrepid (there you can easily switch it off) and nothing newer. During the last months, Wine cleaned up its useage of ALSA a lot. I now have a feeling that it's PA's turn.
Let's have a look at the render.log:
19.114:0026:trace:alsa:AUDDRV_GetAudioEndpoint Opening PCM device "default" with handle_underrun: 0
The handle_underrun shows PA is being used.
19.124:AudioClient_Initialize ALSA period: 480 frames 19.124:AudioClient_Initialize ALSA buffer: 1920 frames 19.124:AudioClient_Initialize MMDevice period: 480 frames 19.124:AudioClient_Initialize MMDevice buffer: 24000 frames
Nothing unusual
19.124:AudioRenderClient_ReleaseBuffer (0x12fcf0)->(24000, 2)
This is the first place in the log where something is going to be played.
19.124:AudioClock_GetPosition snd_pcm_delay failed in state 2: -5 (Input/output error)
That is known from PA when it has not started yet, harmless.
19.124:AudioClient_Start (0x12fcf0) 19.124:alsa_write_data pad: 0
Here the first snd_pcm_write occurs
19.135:alsa_write_data XRun state avail -32, recovering
... and 11ms later, ALSA signals us an underrun...
19.149:alsa_write_data XRun state avail -32, recovering
... from which it never recovers. The rest of the log looks like the render test never managed to play a single tone.
To me it looks like PA with alsa_plugins is unable to produce the values that I come to expect from a good ALSA citizen. In particular, after writing at least 1152 frames (24ms) into an ALSA buffer, I don't expect an underrun 11ms later. That is a bug with either PA/alsa_plugins or Fedora, not Wine, so I'd like a comment from these people. Hence you or I must open a bug on their side.
I restarted PA manually on two machines, one of Intel-HDA and the other with Audigy 2, tried VLC and got the same results.
It's really puzzling that you get no sound on 2 machines. If it were only one, I'd say that Raymond is right to highlight the hw parameters. Perhaps PA/alsa_plugins does not manage to cleanly separate the device's Xms period from the 10ms period that it gave us? If it can't cope with it, PA should not grant a 10ms period on that HW. Wine will be able to cope with a 200ms ALSA period.
That's why again, I'd like to see you select every possible device in winecfg, repeat the render test every time, listen and inspect the log to see whether GetAudioEndpoint etc. were successful or not and what parameters ALSA delivered -- even if using the low-level devices means that PA should be inactive for the duration of the tests. Be aware that there are multiple occurrences of GetAudioEndpoint in a render.log.
Another thing to check is to have dlls/winealsa.drv/mmdevdrv.c: make_handle_underrun_config do nothing by inserting: return NULL; above snd_config_update().
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #33 from Raymond superquad.vortex2@gmail.com 2012-03-04 18:44:30 CST --- vlc seem to be an application which allow use to select mmdevapi, dsound and waveout in the output module
How many device should be listed in
mmdevapi_test mmdevenum
why the registry still keep entry of removed sound card ?
why those entries are still loaded every time when the sound card has been physically removed ?
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #34 from Gilboa Davara gilboad@gmail.com 2012-03-05 00:47:34 CST --- Created attachment 39202 --> http://bugs.winehq.org/attachment.cgi?id=39202 Render test on Audigy 2 (default, multi-channel w/PA, multi-channel w/o PA)
(In reply to comment #32)
If we want to make progress, you must be very precise. What does no go mean?
(Sorry for giving partial information) Selected the actual device "Audigy 2sz" and "Intel HDA" instead of "default".
Ok, but what did you hear from the render test? Occasional crackling? Continuous crackling? No sound at all?
A 5 second long cracking. ... Then short clicks ~10-15 seconds apart.
It is not our intent at all. I've spent hours, evenings, week-ends and nights trying to figure out a way to make PA produce sound reliably. I failed. Even simplest programs (without Wine) managed to see the PA server lose its ability to play any sound from any program. Here's one bug I posted to PA's bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46296 PA is one of the reasons that I'm still using the now unsupported Ubuntu Intrepid (there you can easily switch it off) and nothing newer. During the last months, Wine cleaned up its useage of ALSA a lot. I now have a feeling that it's PA's turn.
I understand the frustration. As a long time Fedora user, I took me ages until I got Pulse to work reliably on my machine. Have you considered trying to contact Lennart Poettering himself? At least in my experience, he's very cooperative.
Let's have a look at the render.log:
19.114:0026:trace:alsa:AUDDRV_GetAudioEndpoint Opening PCM device "default" with handle_underrun: 0
The handle_underrun shows PA is being used.
19.124:AudioClient_Initialize ALSA period: 480 frames 19.124:AudioClient_Initialize ALSA buffer: 1920 frames 19.124:AudioClient_Initialize MMDevice period: 480 frames 19.124:AudioClient_Initialize MMDevice buffer: 24000 frames
Nothing unusual
19.124:AudioRenderClient_ReleaseBuffer (0x12fcf0)->(24000, 2)
This is the first place in the log where something is going to be played.
19.124:AudioClock_GetPosition snd_pcm_delay failed in state 2: -5 (Input/output error)
That is known from PA when it has not started yet, harmless.
19.124:AudioClient_Start (0x12fcf0) 19.124:alsa_write_data pad: 0
Here the first snd_pcm_write occurs
19.135:alsa_write_data XRun state avail -32, recovering
... and 11ms later, ALSA signals us an underrun...
19.149:alsa_write_data XRun state avail -32, recovering
... from which it never recovers. The rest of the log looks like the render test never managed to play a single tone.
To me it looks like PA with alsa_plugins is unable to produce the values that I come to expect from a good ALSA citizen. In particular, after writing at least 1152 frames (24ms) into an ALSA buffer, I don't expect an underrun 11ms later. That is a bug with either PA/alsa_plugins or Fedora, not Wine, so I'd like a comment from these people. Hence you or I must open a bug on their side.
OK. The reason I find the all thing odd, is that both Intel HDA and Audigy 2sx exhibit the exact same behavior under wine, but not under other alsa-plugin applications. Granted, wine use-case may be exercising different code-paths compared to say, Flash player.
It's really puzzling that you get no sound on 2 machines. If it were only one,I'd say that Raymond is right to highlight the hw parameters. Perhaps
PA/alsa_plugins does not manage to cleanly separate the device's Xms period from the 10ms period that it gave us? If it can't cope with it, PA should not grant a 10ms period on that HW. Wine will be able to cope with a 200ms ALSA period.
Again, the title of this bugzilla is misleading. ( I tried changing it but I was requested to revert the change ). I get highly distorted sound, full of crackling and clicks. (Enough so the original wav cannot be identified).
That's why again, I'd like to see you select every possible device in winecfg, repeat the render test every time, listen and inspect the log to see whether GetAudioEndpoint etc. were successful or not and what parameters ALSA delivered -- even if using the low-level devices means that PA should be inactive for the duration of the tests. Be aware that there are multiple occurrences of GetAudioEndpoint in a render.log.
On the Intel HDA, selecting "Intel HDA" instead of system default, produced the same results under winecfg sound test - crackling sound. On the Audigy 2, selecting "Audigy 2ZS - Multi-channel" didn't produce sound or produced the same distorted sound. However, when I killed pulse and used the same winecfg configuration ("Audigy 2zs - Multi-channel") the render test gave me 90% clean sound with some crackling.
Either way: 3 files attached:
Another thing to check is to have dlls/winealsa.drv/mmdevdrv.c: make_handle_underrun_config do nothing by inserting: return NULL; above snd_config_update().
OK, I'll try and free some time to build wine by hand w/ the suggested change.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #35 from Gilboa Davara gilboad@gmail.com 2012-03-05 00:59:02 CST --- (In reply to comment #33)
vlc seem to be an application which allow use to select mmdevapi, dsound and waveout in the output module
How many device should be listed in
mmdevapi_test mmdevenum
$ wine mmdevapi_test mmdevenum mmdevenum.c:105: Device found: {0.0.0.00000000}.{010CF8CE-99D0-4EB3-89F7-CF425CBC00E0} mmdevenum: 32 tests executed (0 marked as todo, 0 failures), 0 skipped.
why the registry still keep entry of removed sound card ?
why those entries are still loaded every time when the sound card has been physically removed ?
No sure I understand. It's a clean prefix and no sound cards have been removed from the machine.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #36 from Raymond superquad.vortex2@gmail.com 2012-03-05 01:23:55 CST --- After I have physically removed au8830 and replaced by ymf724f.
why does wine still reload those entries in registry ?
That 's why I cannot get any sound using "default output module" in vlc it is meanlingless to keep those entries in memory.
some entries may be left when running early version.
trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 adb via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"hw:0,0" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel - AD198x Analog via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"plug:dmix:0" trace:mmdevapi:MMDevice_Destroy Freeing L"ALSA Default" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel - AD198x Analog" trace:mmdevapi:MMDevice_Destroy Freeing L"au8830 - au8830 spdif" trace:mmdevapi:MMDevice_Destroy Freeing L"Yamaha DS-1 (YMF724F) - YMFPCI - IEC958" trace:mmdevapi:MMDevice_Destroy Freeing L"au8830 - au8830 wt" trace:mmdevapi:MMDevice_Destroy Freeing L"PulseAudio Default" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 a3d" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 [au8830 a3d] (hw:0,2) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel - AD198x Headphone" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel [AD198x Digital] (hw:1,1) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"au8830 - au8830 adb" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 spdif" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel - AD198x Digital" trace:mmdevapi:MMDevice_Destroy Freeing L"au8830 - au8830 a3d" trace:mmdevapi:MMDevice_Destroy Freeing L"hw:0" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel [AD198x Analog] (hw:1,0) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"hw:1,0" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 [au8830 wt] (hw:0,3) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 adb via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel [AD198x Headphone] (hw:1,2) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"Yamaha DS-1 (YMF724F) - YMFPCI" trace:mmdevapi:MMDevice_Destroy Freeing L"pulse" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 adb" trace:mmdevapi:MMDevice_Destroy Freeing L"plug:dmix:1" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 [au8830 adb] (hw:0,0) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 [au8830 spdif] (hw:0,1) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"wine" trace:mmdevapi:MMDevice_Destroy Freeing L"default" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 wt" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel - AD198x Analog via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel - AD198x Analog" trace:mmdevapi:MMDevice_Destroy Freeing L"hw:0" trace:mmdevapi:MMDevice_Destroy Freeing L"HDA Intel [AD198x Analog] (hw:1,0) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 - au8830 adb" trace:mmdevapi:MMDevice_Destroy Freeing L"USB Device 0x46d:0x992 - USB Audio" trace:mmdevapi:MMDevice_Destroy Freeing L"hw:1,0" trace:mmdevapi:MMDevice_Destroy Freeing L"Yamaha DS-1 (YMF724F) - YMFPCI" trace:mmdevapi:MMDevice_Destroy Freeing L"Monitor of HDA Intel - AD198x Analog via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"au8830 - au8830 adb" trace:mmdevapi:MMDevice_Destroy Freeing L"PulseAudio Default" trace:mmdevapi:MMDevice_Destroy Freeing L"default" trace:mmdevapi:MMDevice_Destroy Freeing L"Aureal Vortex au8830 [au8830 adb] (hw:0,0) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"wine" trace:mmdevapi:MMDevice_Destroy Freeing L"Monitor of Aureal Vortex au8830 - au8830 adb via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"USB Device 0x46d:0x992 [USB Audio] (hw:2,0) via ALSA" trace:mmdevapi:MMDevice_Destroy Freeing L"USB Device 0x46d:0x992 - USB Audio via PulseAudio" trace:mmdevapi:MMDevice_Destroy Freeing L"ALSA Default"
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #37 from Rosanne DiMesio dimesio@earthlink.net 2012-03-05 06:59:04 CST --- (In reply to comment #36)
After I have physically removed au8830 and replaced by ymf724f.
why does wine still reload those entries in registry ?
This has nothing to do with this bug. File your own bug.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #38 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-05 08:31:06 CST ---
However, when I killed pulse and used the same winecfg configuration ("Audigy 2zs - Multi-channel") the render test gave me 90% clean sound with some crackling.
First, always cross-check in the log which GetAudioEndpoint gets used. I've played with winecfg myself now, setting e.g. "hw:0" or "plug:dmix" via the registry and those devices get removed if winecfg can't access them because PA or plug:dmix clings to some underlying device, e.g. "hw:0". So there's no guarantee that your device of choice gets used. To answer Raymond's question, it won't be removed from the registry either. The only thing that survives the elimination game seems to be "default". This is not ideal, but that is another bug.
Second, the render test may present one small glitch during the "testing shared | exclusive mode" phases, while it sleeps for ~450ms. There should be no glitch during the final "Playing 1 second" phases.
Please report whether the patch attached to bug #30071 cures other crackling. I want 0 crackling when "playing 1 second" with both your audio cards when PA is killed.
Independently, there's a need to go to PA (or Fedora's?) bugtracker, after results from the return NULL hack before snd_config_update().
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #39 from Raymond superquad.vortex2@gmail.com 2012-03-06 00:21:32 CST --- (In reply to comment #34)
Created attachment 39202 [details] Render test on Audigy 2 (default, multi-channel w/PA, multi-channel w/o PA)
A 5 second long cracking. ... Then short clicks ~10-15 seconds apart.
Those creative sound cards need to use "front" , "surround40", ..for multi-channels
The so call "multichannel" playback device of snd-emu10k1 is a 16 channels playback device
Any error message when running "aplay -Dfront any.wav" and "arecord -Dfront -f CD foo.wav" at two terminals at the same time since there are hooks with locks for "front" device"
This is why Pulseaudio server hangs since it use "front" device for playback and capture
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #40 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-06 07:58:16 CST --- BTW, I conducted the following experiment: I had hw:0 locked by speaker-test, so PulseAudio would not be able to grab it (PA0.9.x in Ubuntu Lucid). Nevertheless, the render test had PulseAudio open and write almost a buffer full of samples. Then padding remained frozen at the same value. There never was any error message. I feel Gilboa's situation is somewhat similar, except that underruns are continuously signaled. Neither does PA manage to play audio, nor does it manage to return error codes that would reveal its trouble.
The return NULL hack before snd_config_update() is the last thing to do before going to PA's bugzilla with this issue.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #41 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-07 03:51:41 CST --- Hypothesis: although PulseAudio/alsa_plugins accepts a 10ms period, it is unable to cope with it.
Gilboa, this is your working package:
- in dlls/winealsa.drv/mmdevdrv.c: Initialize, add a multiplier: http://source.winehq.org/source/dlls/winealsa.drv/mmdevdrv.c?v=wine-1.4-rc5#... alsa_period_us = 3 * This->mmdev_period_rt / 10; 3 for 3*10ms, later try 5, 7 or even 12.
- in the same file, change TRACE about XRun pad in alsa_write_data to WARN. Perhaps too the "frames written:" line in GetPosition. With WINEDEBUG=warn+alsa,+timestamp, this will show the important lines without the flood of the full +alsa log.
- Optionally, apply my patch winealsa: Do not hardcode the ALSA buffer size to 4 periods http://www.winehq.org/pipermail/wine-patches/2012-February/111617.html
This will allow to easily play with the ALSA buffer size by setting BufferPeriods. I've used values from 2 to 30. Overall, both will have an effect on the lead-in, i.e. the number of samples that we prefill into the ALSA buffer. You may also play with EXTRA_SAFE_RT.
- Run the render test and listen to sound. On Ubuntu Lucid: o crackling disappears when using a period >= 30ms. o pad:1 can be constantly reported, but that doesn't matter for crackling; o snd_pcm_delay/GetPosition is too slow to indicate a real speaker position, but that doesn't matter for crackling. This causes a variabe amount of test failures, but doesn't matter for crackling in the XAudio2 scenario. o PA appears to drain the buffer using a period from 120-300ms.
- Play with the values. The larger you make them, the more latency you'll introduce, as PA will end up buffering over a second of audio data. Larger latencies will cause more and more problems with winmm and DSound. Try to find a good compromise. pad: >1 in the log is actually not good, as it means that PA's huge internal buffer is already full and PA continues to grab frames that start to fill the ALSA buffer visible to us.
period * 3 and the default BufferPeriods prevented crackling in my limited testing.
- In dlls/mmdevapi/tests/render.c, try frequencies other than 48000 in test_worst_case. Change nSamplesPerSec as in test_formats. Don't forget to update nAvgBytesPerSec as in: http://source.winehq.org/source/dlls/mmdevapi/tests/render.c?v=wine-1.4-rc5#... Here the goal is to assess whether the period + buffer pair you choose above also works when PA's resampler has to process other rates.
I've not assessed the stability of using a larger period, e.g. what if playing for 10000 seconds in test_worst_case. PA is(was?) known to loose sound after some time and need and restart here and then.
http://bugs.winehq.org/show_bug.cgi?id=28622
Don Pobanz dpobanz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dpobanz@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #42 from Raymond superquad.vortex2@gmail.com 2012-03-10 17:49:32 CST --- (In reply to comment #40)
BTW, I conducted the following experiment: I had hw:0 locked by speaker-test, so PulseAudio would not be able to grab it (PA0.9.x in Ubuntu Lucid). Nevertheless, the render test had PulseAudio open and write almost a buffer full of samples. Then padding remained frozen at the same value. There never was any error message.
Does your Pulseaudio server use module-detect or module-udev-detect ?
with only on-board , PA server may load module-null-sink when it cannot find any sound card
after the pulseaudio server is stopped ,if your HDA on-board has analog out and digital out, can you play one stream to analog out and another stream to digital out at the same time
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #43 from Raymond superquad.vortex2@gmail.com 2012-03-10 18:06:55 CST --- (In reply to comment #38)
The only thing that survives the elimination game seems to be "default". This is not ideal, but that is another bug.
No. the default output/input voice outout/voice input in winecfg changed to "(System default)" when wine's version changed or ALSAOutputDevices or ALSAInputDevices contain a device which cannot be openned
It seem that "(System default)" is different from "default"
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #44 from Raymond superquad.vortex2@gmail.com 2012-03-11 03:27:50 CDT --- (In reply to comment #38)
First, always cross-check in the log which GetAudioEndpoint gets used. I've played with winecfg myself now, setting e.g. "hw:0" or "plug:dmix" via the registry and those devices get removed if winecfg can't access them because PA or plug:dmix clings to some underlying device, e.g. "hw:0".
hw:0,0 work only if your hda codecs are cs420x or wm885x which support float
most hda codecs does not support float
you have to manually add "plug:front" , "plug:surroun40" and "plug:surround51" in the ALSAOutputDevices registry for Audigy 2 ZS
http://bugs.winehq.org/show_bug.cgi?id=28622
Hogne Håskjold haskjold@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haskjold@gmail.com
--- Comment #45 from Hogne Håskjold haskjold@gmail.com 2012-03-18 08:59:48 CDT --- Hi
I have the same problem as Gilboa, but on Ubuntu.
I believe I started to experience it when wine reworked it's sound system around mmdevapi.
I've had problems with sound either stopped working altogether, or becoming distorted and stayed that way until a reboot. The distorted sound only happens in wine (winecfg sound test, World of Warcraft, Starcraft 2 as examples). Outside of wine sound works perfectly.
The distorted sound has happened on: Ubuntu 11.10 with wine 1.3.30+, alsa 1.0.24 and pulseaudio 1.0 Ubuntu 12.04 with wine 1.4, alsa 1.0.25 and pulseaudio 1.1
The distortion happens on both a Soundblaster Audigy and a Intel 82801I (ICH9 Family) HD Audio Controller.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #46 from Hogne Håskjold haskjold@gmail.com 2012-03-18 09:08:17 CDT --- Some follow up info:
The messages going to the console when getting distorted sound: ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred ... err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
Not sure if that last one is related to sound though.
"pulseaudio -k" to restart pulseaudio will make sound work for a while in wine again without distortion, but not always.
http://bugs.winehq.org/show_bug.cgi?id=28622
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=46296
--- Comment #47 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-19 08:43:23 CDT --- Hogne, I believe PA's bugtracker is the better place: https://bugs.freedesktop.org/show_bug.cgi?id=46296
There's one single thing that you can try out on the Wine side, namely disable the handle_underrun hack in dlls/winealsa.drv/mmdevdrv.c: static int handle_underrun = 0; (or disable it as indicated at the bottom of comment #32). With that disabled, Wine can claim that it's useage of ALSA is extremely basic and should not cause bugs to appear elsewhere.
until a reboot
You should rarely feel the need to reboot a UNIX. Logging out and in should be enough -- and it's a shame already.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #48 from Gilboa Davara gilboad@gmail.com 2012-03-26 10:36:41 CDT --- Jörg,
Sorry for the late reply. I'll free some time to build a patched Wine RPM (w/ the changes you requested) and report back. I'll also CC myself to the upstream bug report.
- Gilboa
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #49 from Andrew Eikum aeikum@codeweavers.com 2012-09-24 13:54:40 CDT --- Created attachment 41815 --> http://bugs.winehq.org/attachment.cgi?id=41815 winealsa.drv: Feed data at a fixed rate
Hi folks,
I'm attaching a patch here which I hope will improve the situation of Wine with PulseAudio. If you've been having trouble with this setup, please try this patch and see if it improves your situation. I'm especially hopeful that it will fix the "audio stops after a few minutes" bug with PulseAudio.
I am also interested in reports from users without audio problems, to ensure that it doesn't break anything that is currently working.
If you have time to test this out, please report back here with your results.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #50 from Jörg Höhle hoehle@users.sourceforge.net 2012-09-27 03:07:44 CDT --- I've yet to try it out ... Things I noted:
o It's time to add and use: #define QUIRK_PULSE 1 with make_handle_underrun_config: This->quirks |= QUIRK_PULSE;
o if(err < 0 || alsa_period_us < period / 10) Formerly, the check err<0 followed snd_pcm_hw_params_set_period_time_near Now you have a larger cascade involving err<0. Does it do what you want?
o AudioClient_Start + if(This->dataflow == eRender){ + snd_pcm_avail_update(This->pcm_handle); What's the purpose of this? IIRC, PA's avail_update was unreliable before it had really started (or am I confusing that with OSS?).
o There are now 3 timers - CreatetimerQueue - gettimeofday - the ALSA device's timer None of these are sync'ed. I doubt anybody can prove that the code works correctly in the long run. That's my big conceptual gripe.
I too got the feeling that PA might behave when it's not fed too much data, but how to best achieve that without introducing clock skew issues?
Rejuvenation might be another idea, i.e. snd_pcm_close + snd_pcm_open as soon as we detect that PA misbehaves. However IIRC my testing showed that PA's broken state was persistent across client processes.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #51 from Andrew Eikum aeikum@codeweavers.com 2012-10-01 10:05:38 CDT --- (In reply to comment #50)
o It's time to add and use: #define QUIRK_PULSE 1 with make_handle_underrun_config: This->quirks |= QUIRK_PULSE;
Yeah, maybe, but that's a separate issue. This is intended to work better with how ALSA is intended to be used (unreliable timers, so don't rely on avail_update() to determine buffer fullness). We want this behavior in all cases.
o if(err < 0 || alsa_period_us < period / 10) Formerly, the check err<0 followed snd_pcm_hw_params_set_period_time_near Now you have a larger cascade involving err<0. Does it do what you want?
Yeah, I got it a little confused. I'll review that entire sequence, thanks for finding it.
o AudioClient_Start
- if(This->dataflow == eRender){
snd_pcm_avail_update(This->pcm_handle);What's the purpose of this? IIRC, PA's avail_update was unreliable before it had really started (or am I confusing that with OSS?).
It's a leftover from when I tried to use snd_pcm_htimestamp(), which turned out to be unusable. I'll remove it.
o There are now 3 timers
- CreatetimerQueue
- gettimeofday
- the ALSA device's timer
None of these are sync'ed. I doubt anybody can prove that the code works correctly in the long run. That's my big conceptual gripe.
I too got the feeling that PA might behave when it's not fed too much data, but how to best achieve that without introducing clock skew issues?
The biggest issue here is using gettimeofday() instead of snd_pcm_htimestamp(). With htimestamp(), the clock skew would be detected and corrected by the while(diff > period) loop. Unfortunately htimestamp() is unusable. The nice thing about gettimeofday() is that it will always work regardless of ALSA bugs, so I wonder if it isn't worth just ignoring the clock skew issue and letting it under/overrun on occasion.
I'd like to submit this patch very soon, but it would be nice to get confirmation that it works from someone who has been having problems.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #52 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-02 06:50:04 CDT ---
I wonder if it isn't worth just ignoring the clock skew issue I'd like to submit this patch very soon
I oppose this that way. Don't understand me wrong. I'd be pleased to have my old Ubuntu Intrepid work without "pactl exit".
We already have the hack that writes no more than 3-4 periods and preferably full periods. On top of that, you add a rate-limiting hack based on a separate timer. All this just so that PA works, thus the hacks ought to be only active when PA is detected.
What I like about the current audio driver code in Wine is that it's quite straight forward and not too hard to review. We can go to any audio guy and claim: "hey, look at the Wine audio code, it's so simple, any bug must be on your side!".
But by rate-limiting writes based on any timer independent on the audio clock, you would introduce a design fault that would make any audio guy laugh at our driver and not take it seriously.
Quite to the contrary, we might simplify the code even further and solely keep the "write full periods" in the regular driver and put "but no more than 3-4" into the if (This->quirks & PULSE_QUIRK) branch. (Well, I acknowledge that not writing too much in advance minimizes noise when audio shall be paused).
so don't rely on avail_update() to determine buffer fullness
We should not work against the underlying APIs. If it's broken, it need be fixed on their side, but not kludged dramatically on the Wine side. I'm not opposed to small compatibility hacks but broken by design is not acceptable.
Sadly, I've seen no development follow from my PA bug report https://bugs.freedesktop.org/show_bug.cgi?id=46296 Somehow I have the feeling that what they need is somebody to write the tiny pure C code (not my Lisp) that demonstrates how easily PA gets into inconsistent state. Then hopefully we'll see progress...
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #53 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-02 07:04:55 CDT --- The ALSA->PA route appears broken, whereas directly using PA seems to work. Hence Wine might consider adding Maarten's (proven?) Wine->PA route and leave the Wine->ALSA route clean of PA hacks, ready for use by Jack, dmix and hw:0 etc.
Meanwhile we should seek the easily reachable benefits: - I believe Maarten has a DSound patch to use mmdevapi's SetEvent. That would sync both, which is a good thing -- nearly a necessity. - When I'll find time again, I'll have my "stabilize CreateTimerQueue" patches and esp. tests comitted, see bug #30071.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #54 from Andrew Eikum aeikum@codeweavers.com 2012-10-11 11:23:57 CDT --- (In reply to comment #52)
I wonder if it isn't worth just ignoring the clock skew issue I'd like to submit this patch very soon
I oppose this that way. Don't understand me wrong. I'd be pleased to have my old Ubuntu Intrepid work without "pactl exit".
We already have the hack that writes no more than 3-4 periods and preferably full periods. On top of that, you add a rate-limiting hack based on a separate timer. All this just so that PA works, thus the hacks ought to be only active when PA is detected.
This isn't a PA-specific hack, although that is the case that caused me to write the fix. Here's what's happening when the PA bug occurs. The PA plugin limits its reported available size to the remainder of a fake ring buffer. So if the plugin's hw pointer is in the range (ring_buffer_size - period_size, ring_buffer_size) then avail_update() will return (ring_buffer_size - hw_pointer). That means it never reports at least one period available, and winealsa never writes.
If the widely-used and supported PA plugin exhibits this behavior, do you really want to depend on every other device/plugin not performing this way? I don't. We clearly can't depend on avail_update() growing over time, so I'm choosing another way to limit writes.
That argument doesn't even address older OS versions which we still, in theory, support.
Quite to the contrary, we might simplify the code even further and solely keep the "write full periods" in the regular driver and put "but no more than 3-4" into the if (This->quirks & PULSE_QUIRK) branch. (Well, I acknowledge that not writing too much in advance minimizes noise when audio shall be paused).
Actually, the 3-4 period limit has nothing to do with PA. That's there because we can't depend on the ALSA backend implementing pause, so rather than pause the device, we just keep a very small amount of data in it and let it run out for IAudioClient::Stop(). The proper way to fix that is to use snd_pcm_drop()... or snd_pcm_forward()... or write silence... or something else entirely. I don't know. What we have seems to work, so I'm fine sticking with it.
Additionally, if you use the file plugin, then there is no rate limiter at all. You can just write forever and it appears to "play" instantly. That will break any number of applications that use audio play position to control their own behavior.
so don't rely on avail_update() to determine buffer fullness
We should not work against the underlying APIs. If it's broken, it need be fixed on their side, but not kludged dramatically on the Wine side. I'm not opposed to small compatibility hacks but broken by design is not acceptable.
What I like about the current audio driver code in Wine is that it's quite straight forward and not too hard to review. We can go to any audio guy and claim: "hey, look at the Wine audio code, it's so simple, any bug must be on your side!".
The fact is, ALSA is broken and it's not getting fixed until someone defines its behavior, writes unit tests, and fixes the various drivers and plugins. That's not happening any time this decade. gettimeofday(3) is not broken, regardless of the ALSA backend. Yes, there's some risk of clock skew, but that problem is far more preferable to waiting on ALSA to fix their broken crap.
Going back to one of your earlier objections... (In reply to comment #50)
o There are now 3 timers
- CreatetimerQueue
- gettimeofday
- the ALSA device's timer
To eliminate one of the clocks, I tried using ALSA's snd_pcm_status_get_tstamp() and snd_pcm_status_get_htstamp(). Turns out they're broken at least with the PA plugin. They just return 0. Maybe the PA plugin will get fixed some day. Meanwhile gettimeofday(3) will work on every OS in the past couple of decades.
http://bugs.winehq.org/show_bug.cgi?id=28622
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41815|0 |1 is obsolete| |
--- Comment #55 from Andrew Eikum aeikum@codeweavers.com 2012-10-11 11:33:09 CDT --- Created attachment 42072 --> http://bugs.winehq.org/attachment.cgi?id=42072 winealsa.drv: Feed data at a fixed rate
Which brings me to the next version of the patch. This changes it to keep track of the number of frames in ALSA instead of the number of periods. The algorithm is unchanged, but it should be more accurate.
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #56 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-12 05:51:23 CDT ---
So if [...] then avail_update() [...] That means it never reports at least one period available, and winealsa never writes.
Somehow I find it good that you analysed the PA bug in such detail. OTOH, if both of us had spent that many hours fixing PA/alsa-plugins instead of trying to find a work-around, perhaps many people would be pleased, including us.
Still, I do not agree with introducing a broken design into our drivers. What I agree with is:
Try and detect statically ("is this the pulse plugin"?) or dynamically broken drivers and enable the work-around for those and only those.
Dynamic detection may include observing that the driver never reports at least one period available despite several 10ms periods passing by. I myself remember observing PA constantly returning 1 byte free or some such nonsense.
Additionally, if you use the file plugin, then there is no rate limiter at all.
That's a very interesting case I did not consider. It would be covered by dynamic detection of abornal behaviour.
Don't let broken drivers impact treatment of working drivers.
BTW, to anybody reading this, I'd appreciate feedback about Colin Guthrie's tsched=0 suggestion https://bugs.freedesktop.org/show_bug.cgi?id=46296#c3
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #57 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-12 06:34:26 CDT ---
Actually, the 3-4 period limit has nothing to do with PA. [...]
Your explanation is correct except for one point.
We *could* use snd_pcm_drop, however it would introduce observable behaviour different from native and I've written the tests in Wine to catch that deviation. Namely, the effect upon GetCurrentPadding (lost frames).
I believe we'll have to re-evaluate that decision some day. The drawback of the 3-4 periods limit is bug #29531 and such. Audio currently very much depends on Linux always waking up our threads often enough within this 30ms limit. There's no guarantee for that! The log in that other bug looks like there was a 100ms delay out of the blue.
You can bet that native's audio engine has one of the highest priorities. Maarten is right to beg for real-time priorities, although I don't see that happen for Wine (I too consider RT too dangerous in Wine). So we need to find ways to buffer much more.
So in principie, we may have to decide to agree to let some tests fail (well, change them), let GetCurrentPadding decrease much more than native's at the benefit of allowing the audio driver to buffer much more than meager 30-40ms.
The pre-1.3.25 winmm drivers used much larger buffers (as large as the application provided, e.g. 333ms from our MCIWAVE device) and hence did not suffer from jitter or scheduler arbitrations.
OTOH, Wine's dsound has always used 10ms periods. I've not analysed how much data the old driver sent to the ALSA/OSS driver in advance.
And we've not yet analysed in sufficient depth what else we can do on the Wine side to help the Linux scheduler call our audio driver very often. Too many critical sections? Too many thread convoys?
The only advice I found to maintain a high rank in Linux scheduler's priority is: "do your little work fast, then wait/sleep".
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #58 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-18 00:53:09 CDT --- - if(snd_pcm_state(This->pcm_handle) == SND_PCM_STATE_XRUN || - avail > This->alsa_bufsize_frames){ + if(snd_pcm_state(This->pcm_handle) == SND_PCM_STATE_XRUN){ IMHO that's a good hint that the suggested This->quirks flag is needed.
We set snd_pcm_sw_params_set_stop_threshold(This->alsa_bufsize_frames) thus we expect XRUN to be signaled should avail grow beyond that. Yet I remember observing a large avail without XRUN or sound with some devices and that's why the extra check makes sense -- as a safety. Resetting is a means of rejuvenation.
With pulse, things are different, again. IIRC I observed huge avails, yet no audible overrun had happened and it could not have played all the data that I had sent by that time. So this check is somehow not appropriate for a broken pulse ALSA plugin when one wants to keep it playing. (OTOH one may argue that such huge avail is already an indication of broken state in pulse -- too late).
I think it would be good to split the buffer sizing from the rate limiting patch.
+ snd_pcm_hw_params_set_buffer_size_min( + snd_pcm_hw_params_set_periods_min( MAX_FED=4 ) Why hard limits? I've seen all kinds of ALSA periods from 2 to 500ms.
One of my TODO notes is about making sure that our driver accommodates nearly all ALSA periods and buffer sizes, i.e. that it decouples native's 10ms shared mode periods sufficiently from ALSA's behaviour.
set_*_near helps. Anything else presumably stands in the way.
Another TODO goal is to make our driver works with solely 2 ALSA periods, much like the traditional 2 buffer ping pong technique. This ought to work with ALSA periods > mmdevdrv 10ms periods.
Yet another TODO goal is to double check the limits in our driver by playing with mmdevdrv period sizes from 10ms to the 500ms that native allows (in exclusive mode). E.g. 4 ALSA periods will likely not be granted with 500ms periods -- but in that setting we don't need 4 periods. 2 shall be enough.
All these TODO require a lot of time...
BTW, the old code had one WARN(err, snd_strerror(err)) per failed call to snd_pcm_*. So we knew how ALSA reacted to each and every call.
Both PulseAudio and Jack seem to favour large 50-150ms periods over native 10ms. It should not be really surprising if snd_pcm_avail stalls within one period. Yet I don't think we handle that well. I had a sketch of a driver that decremented padding regularly in 10ms intervals regardless of ALSA periods but IIRC that was not one that would feed ALSA in ALSA-period-sized chunks. Given the number of min(..., to_write_frames) in your patch, it doesn't look like the code still tries to do that. Well, that may have been good with hw and dmix devices, but is dubious with large "virtual" 50-150ms periods from PA or Jack: better feed the 10ms snippets that XA2 gives us each round.
About the code, I think the while loop should contain one single alsa_write_best_effort and delegate repeating to the loop. I believe I found a flaw in the fed_frames updates that can make it overflow. And I suggest you invert the meaning of fed_frames, i.e. have fed_frames>N like avail>N or held_frames>N mean that N can be written.
http://bugs.winehq.org/show_bug.cgi?id=28622
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #59 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-24 14:23:33 CDT --- Andrew, here's test data that I'm afraid kills your patch. Please run the mmdevapi render tests using testrun -v -i, i.e. with WINETEST_INTERACTIVE=1 and WINETEST_DEBUG=2 at least.
random native w7 machine from test.winehq: This is the behaviour that wine MUST reach in order to support the growing number of apps that use XA2 with minimal buffer size. render.c:2084: Should play 1000ms continuous tone with fragment size 480. render.c:2136: Released 48000=100x480 -960 frames at 48000 worth 980ms in 1008ms
PA (Ubuntu Hardy) with Andrew's patch -- crackling sound like noise render.c:2084: Should play 1000ms continuous tone with fragment size 480. render.c:2136: Released 32640=68x480 -480 frames at 48000 worth 670ms in 1204ms
dmix (Ubuntu Hardy) with Andrew's patch -- crackling sound like noise render.c:2136: Released 39360=82x480 -821 frames at 48000 worth 803ms in 1210ms render.c:2084: Should play 1000ms continuous tone with fragment size 480.
dmix (Ubuntu Hardy) wine-1.5.15 -- a little regular crackling render.c:2136: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1196ms render.c:2084: Should play 1000ms continuous tone with fragment size 480.
PA (Ubuntu Hardy) wine-1.5.15 -- a little irregular crackling sound render.c:2084: Should play 1000ms continuous tone with fragment size 480. render.c:2136: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1198ms
"worth 980ms" means that in 98% of cases, after an event tick, padding had decreased enough for the XA2 algorithm to add more frames. Any lower value means gaps and loss of sync between audio and video.
"in 1008ms" is elapsed time. If it differs too much from "worth" it means that gaps were introduced. Small gaps produce a crackling sound. If it differs too much from "should play" it means that the timer(Queue) used did not deliver on schedule. It could be jitter or systematic. That's when I investigated timers and wrote the CreateTimerQueue stabilisator patch.
With the TQ stabilisator patch, I get similar values with or without PA, with or without your patch: render.c:2136: Released 44160=92x480 -480 frames at 48000 worth 910ms in 1000ms render.c:2084: Should play 1000ms continuous tone with fragment size 480. even upto 960ms and almost continuous tone with PA: render.c:2136: Released 46560=97x480 -480 frames at 48000 worth 960ms in 1000ms render.c:2084: Should play 1000ms continuous tone with fragment size 480.
In summary, we already have a good tool to check how well the wine* drivers perform. It even allows to quantify the quality. As you can see, the winealsa drivers are not good enough yet on some systems.
http://bugs.winehq.org/show_bug.cgi?id=28622
Johan Gardhage johan.gardhage@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #60 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.37 or newer) wine? If so, please attach the terminal output in 1.7.37 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=28622
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #61 from Ken Sharp imwellcushtymelike@gmail.com --- Abandoned
https://bugs.winehq.org/show_bug.cgi?id=28622
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #62 from Bruno Jesus 00cpxxx@gmail.com --- Closing abandoned bugs.
https://bugs.winehq.org/show_bug.cgi?id=28622
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|spetreolle@yahoo.fr |
-
wine-bugs＠winehq.org