[Bug 39744] New: No sound in Applications after Update from 1.7 pre winepulse.drv to 1.7.55 or 1.8 after the pulse update
https://bugs.winehq.org/show_bug.cgi?id=39744
Bug ID: 39744 Summary: No sound in Applications after Update from 1.7 pre winepulse.drv to 1.7.55 or 1.8 after the pulse update Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: NoYzE@hotmail.de Distribution: ---
Created attachment 53014 --> https://bugs.winehq.org/attachment.cgi?id=53014 a log of the occuring problem with audio debug enabled
I updated from a 1.7 Wine version where my default sound driver was winealsa.drv. I wanted to use a newer version of Wine and updated to 1.7.55. I noticed, the default driver has changed to winepulse.drv and winecfg plays the test sound fine.
However in applications i have no sound at all. I tried purging pulseaudio, alsa, wine and reinstall and deleting .wine
In the wine irc, "slackner" asked me for a log and i generated one, showing lots of "warn:pulse:AudioRenderClient_GetBuffer Wanted to write 7200, but only 2646 available" warnings.
I don't think i have made any changes to the pulse config, however i used the music programm LMMS to make music. In the settings there is a slider to turn the Latency up down through buffer size, but i don't think it's globally. Also turning buffer size up there now doesn't affect the problem, so i think it's not connected. Besides i did no changes to Pulse or Alsa i think.
I tested with Games like Warcraft III, Hearthstone and Osu!
I am running Debian Testing 64-bit Gnome3 Nvidia-Drivers installed.
https://bugs.winehq.org/show_bug.cgi?id=39744
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com, | |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #1 from NoYzE@hotmail.de --- Changing the sample-rate in daemon.conf is the only thing i found that effects the but only xxxx available number. And only very slightly.
https://bugs.winehq.org/show_bug.cgi?id=39744
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@redhat.com Component|-unknown |winepulse.drv
https://bugs.winehq.org/show_bug.cgi?id=39744
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@mblankhorst.nl
--- Comment #2 from Andrew Eikum aeikum@codeweavers.com --- Thanks for the nice bug report! Could you attach your </etc/pulse/daemon.conf> file?
It looks like the pulse buffer is very small compared to what we request. After configuring the stream for 32-bit 2-channel audio, we get these attributes:
trace:pulse:dump_attr maxlength: 4194304 trace:pulse:dump_attr minreq: 5288 trace:pulse:dump_attr fragsize: 21168 trace:pulse:dump_attr tlength: 21168 trace:pulse:dump_attr prebuf: 15888
"tlength" is the important one. 21168 is 2646 frames which is a duration of 0.06 seconds. Later, the application tries to write a buffer of 7200 frames (0.16 seconds), which obviously doesn't fit into that buffer, and fails.
So I wonder why PA is giving us such a tiny buffer? If that's valid behavior for PA, then in order to meet the mmdevapi contract, winepulse should store data locally and feed it to PA as space is made available.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #3 from NoYzE@hotmail.de --- Created attachment 53033 --> https://bugs.winehq.org/attachment.cgi?id=53033 My /etc/pulse/daemon.conf
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #4 from NoYzE@hotmail.de --- Thanks for the response. My daemon.conf should be vanilla. I'll attach it :) I'll be looking for other locations of config files that might be altered. But it's strange enough that apt-get purge pulseaudio* and apt-get purge wine* did not work. Also (i know i shouldn't) i ran wine through sudo once and the sound worked. But there was some error about Pulse so i don't know if there was something like a fallback to the Alsa-Pulse-Plugin.
https://bugs.winehq.org/show_bug.cgi?id=39744
jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
--- Comment #5 from jre.winesim@gmail.com --- In case you are using the debian.org packages, there we export PULSE_LATENCY_MSEC=60 per default. Without being familiar with this topic this looks to me like the explanation for the small buffer size, as described by Andrew Eikum in comment #3.
In that case, try something like: PULSE_LATENCY_MSEC=160 wine /path/to/your/app
btw: exactly which WINEDEBUG setting did you use?
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #6 from Andrew Eikum aeikum@codeweavers.com --- (In reply to jre.winesim from comment #5)
In case you are using the debian.org packages, there we export PULSE_LATENCY_MSEC=60 per default.
That does seem to be relevant. Did you do this to help the winealsa driver along? If so, it should no longer be needed with winepulse.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #7 from jre.winesim@gmail.com --- (In reply to Andrew Eikum from comment #6)
(In reply to jre.winesim from comment #5)
In case you are using the debian.org packages, there we export PULSE_LATENCY_MSEC=60 per default.
That does seem to be relevant. Did you do this to help the winealsa driver along? If so, it should no longer be needed with winepulse.
It was to avoid stuttering (https://bugs.debian.org/581624). So I guess this is a yes and we should just remove that completely again.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #8 from NoYzE@hotmail.de --- YES! It's working! I did use the Debian.org Package, right and i know what you mean by helping with stuttering, cause i had this problem with the old winealsa.drv and used to set PULSE_LATENCY_MSEC to 30 to fix that. I use WINEDEBUG=+pulse (got that command from "slackner" in the wine irc). With "WINEDEBUG=+pulse PULSE_LATENCY_MSEC=150 wine" the buffer size was drastically increased and with "WINEDEBUG=+pulse PULSE_LATENCY_MSEC=200 wine" i finally got sound :) But is it normal to need 200ms with pulse instead of the prior 30ms with alsa? I hope the sound isn't somewhat lagging behind this way.
However many many thanks to sort that out so i can have sound again :)
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #9 from Andrew Eikum aeikum@codeweavers.com --- (In reply to NoYzE from comment #8)
But is it normal to need 200ms with pulse instead of the prior 30ms with alsa?
The short answer is there's no actual latency difference.
In winepulse, we don't do any local buffering. We depend on PulseAudio to give us the full buffer size that the application requested. In winealsa, however, we do buffer locally because ALSA makes no guarantees about the allocated buffer size. That means the small PA latency setting will be absorbed by winealsa's local buffer, instead of causing underruns like it does with winepulse.
It's possible that winepulse should buffer locally, too, to account for setups like yours. On the other hand, maybe users are expected to let PA do its latency calculations itself, and so testing with that environment variable set is invalid. I don't know.
I've forgotten (or never knew) the precise details of why it helped, but setting the environment variable when using winealsa with PulseAudio would change the buffering characteristics of the alsa-pulse plugin and help prevent underruns. With winepulse, it's no longer needed since the alsa-pulse plugin is no longer used.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #10 from jre.winesim@gmail.com --- (In reply to NoYzE from comment #8)
YES! It's working!
Good to hear.
Can you please remove the offending code ("PULSE_LATENCY_MSEC=$latency") from the last line of /usr/bin/wine and then retest in a clean encironment (without PULSE_LATENCY_MSEC being set)? I'd like to verify that you still get sound then, and the stuttering stays away. (As it really should be the case.) I'll commit a fix in Debian then.
Thanks Andrew for the explanations.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #11 from NoYzE@hotmail.de --- Yea thanks Andrew!
I removed the var and tested before/after and yes, i have the "only 2646 available" warning with the line and great working sound without it. I tested some time now and i have stable sound without stuttering or drops that i had with the winealsa.drv
Great work!
https://bugs.winehq.org/show_bug.cgi?id=39744
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Version|unspecified |1.7.55 Summary|No sound in Applications |No sound with winepulse.drv |after Update from 1.7 pre |in multiple applications |winepulse.drv to 1.7.55 or |when using Debian Wine |1.8 after the pulse update |packages | |(PULSE_LATENCY_MSEC set to | |60 in wine wrapper script) Ever confirmed|0 |1 Severity|normal |enhancement
--- Comment #12 from Sebastian Lackner sebastian@fds-team.de --- I was already aware that Debian applies invalid/unnecessary patches, provides unnecessary and broken wrapper scripts, and so on ... - but the fact that they also sets Pulseaudio specific environment variables is new to me.
(In reply to Andrew Eikum from comment #9)
It's possible that winepulse should buffer locally, too, to account for setups like yours. On the other hand, maybe users are expected to let PA do its latency calculations itself, and so testing with that environment variable set is invalid. I don't know.
I would say, lets keep this bug report open as an enhancement, unless we have evidence that it also occurs in a setup without environment variable overrides. We probably should promote the WARN() to a winediag message though, to catch such invalid user setups a bit easier. Do you agree?
https://bugs.winehq.org/show_bug.cgi?id=39744
Javier Cantero jcantero@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jcantero@gmail.com
--- Comment #13 from Javier Cantero jcantero@gmail.com ---
We probably should promote the WARN() to a winediag message though, to catch such invalid user setups a bit easier.
That would be appropriate. This bug was driving me crazy, thinking about some kind of weird sound driver-pulseaudio interaction that I alone had, because of the lack of similar bug reports. Also there are so many web pages out there that recommend to change this fragment-ms value (via environmental variable or daemon.conf configuration file) that the bug is likely to be present for a while.
It would be also nice to document the new WARN() somewhere in http://wiki.winehq.org/Sound
https://bugs.winehq.org/show_bug.cgi?id=39744
Mathew Hodson mathew.hodson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mathew.hodson@gmail.com
--- Comment #14 from Mathew Hodson mathew.hodson@gmail.com --- Since this bug only affects the Debian packages, Debian should be set in the Distribution field.
https://bugs.winehq.org/show_bug.cgi?id=39744
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian
https://bugs.winehq.org/show_bug.cgi?id=39744
Mathew Hodson mathew.hodson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mathew.hodson@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=39744
Marek Rusinowski marekrusinowski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marekrusinowski@gmail.com
--- Comment #15 from Marek Rusinowski marekrusinowski@gmail.com --- *** Bug 39800 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #16 from Andrew Eikum aeikum@codeweavers.com --- jre, has this been removed from the Debian Wine package? Would you like an upstream bug filed?
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #17 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Andrew Eikum from comment #16)
jre, has this been removed from the Debian Wine package? Would you like an upstream bug filed?
The latest version in Debian repos is 1.7.55-4 (on Stretch and Sid), which still contains the line with PULSE_LATENCY_MSEC. If someone here is motivated enough to improve those packages and/or to file bug reports for all the individual issues, I am aware of several other problems besides the PULSE_LATENCY_MSEC environment variable, which should be fixed too.
Starting from unnecessary patches (file-handling.patch is not necessary anymore, the bug is already fixed upstream - applying the patch nevertheless breaks tests), missing wrapper scripts (frequent user complaints about missing "wineconsole" and other winelib apps), questionable design decisions (WINEDEBUG=-all is used by default, making bug reports here useless), and so on. There were even more problems, and also the build itself is highly questionable. Various autogenerated files (unicode tables, OpenGL extension tables, wineserver request tables) are regenerated during the build process, which potentially introduces new bugs / incompatibilities not present in official WineHQ builds.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #18 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Sebastian Lackner from comment #17)
(In reply to Andrew Eikum from comment #16)
jre, has this been removed from the Debian Wine package? Would you like an upstream bug filed?
The latest version in Debian repos is 1.7.55-4 (on Stretch and Sid), which still contains the line with PULSE_LATENCY_MSEC. If someone here is motivated enough to improve those packages and/or to file bug reports for all the individual issues, I am aware of several other problems besides the PULSE_LATENCY_MSEC environment variable, which should be fixed too.
This https://packages.debian.org/stretch/wine shows 1.8-rc3.
Various autogenerated files (unicode tables, OpenGL extension tables, wineserver request tables) are regenerated during the build process, which potentially introduces new bugs / incompatibilities not present in official WineHQ builds.
That should not be a problem if they want to regenerate from Unicode data, as we depend on particular versions of those that don't change once released. But sure, there's no need to do that in practice.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #19 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Nikolay Sivov from comment #18)
This https://packages.debian.org/stretch/wine shows 1.8-rc3.
Ah, thanks for pointing this out. I was looking at the "wine-development" package which used to be more up-to-date during the last year, but seems its now exactly the other way round? I'm wondering how users should stay up-to-date when they have to switch the package inbetween.
Various autogenerated files (unicode tables, OpenGL extension tables, wineserver request tables) are regenerated during the build process, which potentially introduces new bugs / incompatibilities not present in official WineHQ builds.
That should not be a problem if they want to regenerate from Unicode data, as we depend on particular versions of those that don't change once released. But sure, there's no need to do that in practice.
I still see a high risk of introducing new problems. See for example the OpenGL tables, which are generated based on the XML files shipped in the "khronos-api" package. Last update is from March 2015, but in Wine we had a commit to update them in April for example.
Also, in order to regenerate various files, they are first replaced with an "empty" version, then the script is executed - however, not all of those files are static. They can easily get out of sync with the Wine source tree.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #20 from jre.winesim@gmail.com --- (In reply to Andrew Eikum from comment #16)
jre, has this been removed from the Debian Wine package? Would you like an upstream bug filed?
Yes, it's been removed from Debian in wine 1.8~rc4-1, which has been uploaded to sid (unstable) on 2015-12-12. It will probably migrate to stretch (testing) on 2015-12-18. Jessie and jessie-backports (stable) are not affected, because there are no pulse-enabled packages in there (yet).
The wine-development packages 1.7.55-4 in stretch (testing) and sid (unstable) are affected, they will be fixed with the first 1.9.x upload. Again stable (including backports) is not affected.
What do you mean with upstream? (For me this is winehq, and we have this bugreport here. In Debian we had https://bugs.debian.org/807403, that's what led me here). So I think no need for a new bugreport.
I will notify this bug when a fixed version is in testing (hopefully in 3 days) and when wine-development 1.9.x reaches testing (that might be in 4 weeks). Then this issue will be completely fixed in every updated Debian installation.
I take it that the winehq side of this problem is also taken care of with: commit a599ea83c8148685c2b3e69102aaf4cf3c2d48f3 Author: Andrew Eikum aeikum@codeweavers.com Date: Thu Dec 10 10:35:55 2015 -0600 winepulse.drv: Print a winediag error when PA buffer size is too small.
Greets jre
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #21 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Sebastian Lackner from comment #19)
(In reply to Nikolay Sivov from comment #18)
This https://packages.debian.org/stretch/wine shows 1.8-rc3.
Ah, thanks for pointing this out. I was looking at the "wine-development" package which used to be more up-to-date during the last year, but seems its now exactly the other way round? I'm wondering how users should stay up-to-date when they have to switch the package inbetween.
The logic is probably to name it 'wine' for stable releases, and 'wine-development' for biweekly releases.
Various autogenerated files (unicode tables, OpenGL extension tables, wineserver request tables) are regenerated during the build process, which potentially introduces new bugs / incompatibilities not present in official WineHQ builds.
That should not be a problem if they want to regenerate from Unicode data, as we depend on particular versions of those that don't change once released. But sure, there's no need to do that in practice.
I still see a high risk of introducing new problems. See for example the OpenGL tables, which are generated based on the XML files shipped in the "khronos-api" package. Last update is from March 2015, but in Wine we had a commit to update them in April for example.
Right, I can only speak about Unicode data files, because that's what I touched. If some files are not versioned and are constantly updated then it's a potential breakage. And actually now that I double checked not all Unicode data files are in versioned dirs, so this is affected too (not in practice because it's very unlikely they will ever update those).
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #22 from jre.winesim@gmail.com --- [Not sure if we should move discussion about unrelated Debian/Wine topics to wine-devel. But since this bug is mostly taken care of now, it doesn't hurt too much discussing it here.]
--- Comment #17 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Andrew Eikum from comment #16)
jre, has this been removed from the Debian Wine package? Would you like an upstream bug filed?
The latest version in Debian repos is 1.7.55-4 (on Stretch and Sid), which still contains the line with PULSE_LATENCY_MSEC. If someone here is motivated enough to improve those packages and/or to file bug reports for all the individual issues, I am aware of several other problems besides the PULSE_LATENCY_MSEC environment variable, which should be fixed too.
Agreed, filing bug reports at bugs.debian.org for issues relating to Debian is probably the most constructive way. It's as easy as sending a mail to submit@bugs.debian.org, with the following first lines (Debian users should use "reportbug"):
Source: wine (or wine-development) Version: 1.8~rc4-1 (must be a valid Debian version) Severity: normal (or wishlist, higher severities might be counterproductive)
Use these links to see the current version for every dist (not only testing or whatever): https://packages.debian.org/wine (stable releases, including RC) https://packages.debian.org/wine-development (the rest)
file-handling.patch is not necessary anymore, the bug is already fixed upstream - applying the patch nevertheless breaks tests
Thanks for pointing that out, I just removed that in the Debian git repo.
frequent user complaints about missing "wineconsole" and other winelib apps
I'm only aware of wineconsole (https://bugs.debian.org/792695), which was fixed 2015-11-21. I'm not sure though, if we should create symlinks for every possible app (currently we have regedit, winecfg, winedbg, wineboot, winepath, winefile, regsvr32 and wineconsole.) Maybe add msiexec to the wine package, and the rest to the -tools packages which are optional. Without symlink every app still may be called with "wine [app]".
WINEDEBUG=-all is used by default, making bug reports here useless
Agreed. But that way you can at least see that the bug report is coming for a debian.org package ;->
(In reply to Sebastian Lackner from comment #19)
(In reply to Nikolay Sivov from comment #18)
Various autogenerated files (unicode tables, OpenGL extension tables, wineserver request tables) are regenerated during the build process, which potentially introduces new bugs / incompatibilities not present in official WineHQ builds.
That should not be a problem if they want to regenerate from Unicode data, as we depend on particular versions of those that don't change once released. But sure, there's no need to do that in practice.
I still see a high risk of introducing new problems. See for example the OpenGL tables, which are generated based on the XML files shipped in the "khronos-api" package. Last update is from March 2015, but in Wine we had a commit to update them in April for example.
Also, in order to regenerate various files, they are first replaced with an "empty" version, then the script is executed - however, not all of those files are static. They can easily get out of sync with the Wine source tree.
[I haven't really looked into the specific regenerate stuff that we do in Debian-Wine or am a general expert for this.] Generally Debian requires to build from source. And downloading during a package build (e.g. wget --no-check-certificate https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml) is a no-go (or I guess and hope so). [Unless I'm completly mistaken:] this topic reminds me of Debian's recent discussion about minified javascript code (https://lists.debian.org/debian-devel/2015/08/msg00427.html). That thread might help to understand Debian's position. If there is a better way to regenerate these files, I'd be happy to hear about it.
I'm not sure how to best handle updates of e.g. khronos. Maybe add such changes to Wine's release announcement, like it is done for gecko?
I now filed a bugreport for an updated khronos-api package.
Greets jre
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #23 from Andrew Eikum aeikum@codeweavers.com --- Thanks, jre.
I think we should leave this bug open unless we can get confirmation that the behavior seen by the original reporter is unexpected behavior from PulseAudio. Probably we should do local buffering in winepulse if PA can't give us the full buffer we request. But I don't think it's urgent.
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #24 from jre.winesim@gmail.com --- Thank you, Andrew!
1.8~rc4-1 is now in Debian testing. So no affected 1.8.x packages in the Debian repositories.
https://bugs.winehq.org/show_bug.cgi?id=39744
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=39814
https://bugs.winehq.org/show_bug.cgi?id=39744
--- Comment #25 from Jens Reyer jre.winesim@gmail.com --- fyi: All wine and wine-development packages shipped in Debian (stable, backports, testing, unstable) aren't affected/fixed by now. They are either pre-pulseaudio or have the PULSE_LATENCY_MSEC removed from the wrapper script.
(In reply to Andrew Eikum from comment #23)
I think we should leave this bug open unless we can get confirmation that the behavior seen by the original reporter is unexpected behavior from PulseAudio. Probably we should do local buffering in winepulse if PA can't give us the full buffer we request. But I don't think it's urgent.
Maybe someone retitle the bug and remove the Debian tag again?
Greets and thanks to all jre
https://bugs.winehq.org/show_bug.cgi?id=39744
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|No sound with winepulse.drv |No sound with winepulse.drv |in multiple applications |in multiple applications |when using Debian Wine |when PulseAudio fails to |packages |allocate full buffer |(PULSE_LATENCY_MSEC set to | |60 in wine wrapper script) |
--- Comment #26 from Andrew Eikum aeikum@codeweavers.com --- I believe this is fixed by the following commit. Like jre said, Debian no longer sets this environment variable, but if it did, I think it would work again. I asked in #pulseaudio, and someone said that Pulse makes no guarantees about its buffer sizes. So, we have to buffer data locally when it fails to allocate the full buffer requested by the application. Setting PULSE_LATENCY_MSEC was one way to do this, but I think some hardware or other software configuration can also cause Pulse to fail to allocate the full buffer.
I'll close this bug in a bit if I don't hear any more feedback.
commit 1245f8335c31a6078ed50fc17cff4d60877c72a4 Author: Andrew Eikum aeikum@codeweavers.com Date: Fri Feb 19 10:48:24 2016 -0600
winepulse.drv: Buffer data locally when needed.
https://bugs.winehq.org/show_bug.cgi?id=39744
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|Debian |---
https://bugs.winehq.org/show_bug.cgi?id=39744
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com, | |winetest@luukku.com
--- Comment #27 from winetest@luukku.com --- (In reply to Andrew Eikum from comment #26)
I believe this is fixed by the following commit. Like jre said, Debian no longer sets this environment variable, but if it did, I think it would work again. I asked in #pulseaudio, and someone said that Pulse makes no guarantees about its buffer sizes. So, we have to buffer data locally when it fails to allocate the full buffer requested by the application. Setting PULSE_LATENCY_MSEC was one way to do this, but I think some hardware or other software configuration can also cause Pulse to fail to allocate the full buffer.
I'll close this bug in a bit if I don't hear any more feedback.
commit 1245f8335c31a6078ed50fc17cff4d60877c72a4 Author: Andrew Eikum aeikum@codeweavers.com Date: Fri Feb 19 10:48:24 2016 -0600
winepulse.drv: Buffer data locally when needed.
No response in several months. Sounds fixed.
https://bugs.winehq.org/show_bug.cgi?id=39744
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |1245f8335c31a6078ed50fc17cf | |f4d60877c72a4 Status|NEW |RESOLVED
--- Comment #28 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to winetest from comment #27)
(In reply to Andrew Eikum from comment #26)
I believe this is fixed by the following commit. Like jre said, Debian no longer sets this environment variable, but if it did, I think it would work again. I asked in #pulseaudio, and someone said that Pulse makes no guarantees about its buffer sizes. So, we have to buffer data locally when it fails to allocate the full buffer requested by the application. Setting PULSE_LATENCY_MSEC was one way to do this, but I think some hardware or other software configuration can also cause Pulse to fail to allocate the full buffer.
I'll close this bug in a bit if I don't hear any more feedback.
commit 1245f8335c31a6078ed50fc17cff4d60877c72a4 Author: Andrew Eikum aeikum@codeweavers.com Date: Fri Feb 19 10:48:24 2016 -0600
winepulse.drv: Buffer data locally when needed.No response in several months. Sounds fixed.
Assuming fixed after 5 months.
https://bugs.winehq.org/show_bug.cgi?id=39744
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #29 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.16.
https://bugs.winehq.org/show_bug.cgi?id=39744
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.8.x
https://bugs.winehq.org/show_bug.cgi?id=39744
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |---
--- Comment #30 from Michael Stefaniuc mstefani@redhat.com --- Removing 1.8.x milestone from bugs included in 1.8.5.
-
wine-bugs＠winehq.org