Closing.
]]>It appears as though switching the wine version in POL causes sound to stop working, regardless of what version you're changing to / from. After rebooting, sound will once again work regardless of which wine version is currently selected. Changing the wine version once again breaks the sound. Some have mentioned that the system version works; I find this to not be the case when switching from another version to system.
I should mention that I am using a 32-bit wine prefix, which probably where the bug lies. I have seen forums where posters have mentioned that they do not have these issues in the 64-bit version, so unless you really need a 32-bit prefix, it's probably better to just create a 64-bit prefix. I have not tested with a 64-bit prefix myself.
TL;DR: Open POL, choose the wine version, reboot computer, play game, great success.
]]>/etc/pulse/daemon.conf
default-fragment-size-msec = 5settings this setting to 5 finally solved my sound problems with pulseaudio 5.0 and wine.
works with diablo 3, world of warcraft and starcraft 2
This fixed my problem with Unity 3D running through Wine.
Sound would be distorted and pulseaudio CPU usage would be close to 100%.
In pavucontrol I would see the playback stream from "ALSA plug-in [wine-preloader]" constantly appearing/disappearing many times per second.
WINE=1.7.14-imm32_bug35361
export WINESERVER="$HOME/.PlayOnLinux/wine/linux-amd64/$WINE/bin/wineserver"
export WINELOADER="$HOME/.PlayOnLinux/wine/linux-amd64/$WINE/bin/wine"
export WINEDLLPATH="$HOME/.PlayOnLinux/wine/linux-amd64/$WINE/bin/lib/wine"
export WINEPREFIX="$HOME/.PlayOnLinux/wineprefix/SteamFix"
$HOME/.PlayOnLinux/wine/linux-amd64/$WINE/bin/wine "/windows/Program Files (x86)/Steam/Steam.exe" -no-dwrite
#$HOME/.PlayOnLinux/wine/linux-amd64/$WINE/bin/winecfg
I know that one, this is because you are not actually running PoL's version of wine anymore but using the system installed wine with the prefix set to that path. There are more variables you have to switch around AND you have to call the actual binary pol installs, I am not on my arch right now so I don't have an example handy. That said Im pretty sure PoL called winecfg worked with the 64bit build, but I'm going to confirm that when I'm home
I don't think that's the case, since I'm not running the system winecfg; I'm calling winecfg from the wine version installed under .Playonlinux (so in my example, I call ~/.PlayOnLinux/wine/linux-amd64/1.7.10/bin/winecfg), and I'm running it in the wineprefix under ~/.PlayOnLinux (i.e. in ~/.PlayOnLinux/wineprefix/<prefix name>), not ~/.wine.
]]>That 64-bit wine is looking for 32-bit libraries is normal and to be expected, I doubt that running pol-git will change anything as the builds of the wine version seems to have issue (I guess) which are independent of the actual playonlinux version, but whats weird is that you still got the crash... I only have one wine 64bit version that i was interested in (the one I linked to in an earlier post), and this one works in 64bit but not in 32... BUT I also don't invoke it via playonlinux, I just used it to get the wineversion and I've made a script that sets the necessary environment variables and then starts the game directly, so maybe something additional that pol does on running things conflicts here...
Do you get the crash if you run winecfg via pol?
I did note one thing though: say I've set pol to use Wine 1.7.10 64-bit for a game (and I've run the game successfully before). Now if I manually run winecfg in that game's directory (by setting WINEPREFIX to the game's directory first, and running <path to wine 1.7.10 64-bit>/bin/winecfg, then wine pops up the dialog that it shows when running for the first time in a particular wineprefix (which says it's updating the wine config in that wineprefix). This is unexpected; since pol has already run this version of wine in this wineprefix before, shouldn't wine remember that fact?
]]>Can you confirm PA 5.0 works with playonlinux-git from the AUR?
I can confirm that the problem still exists with playonlinux-git. My system is a x86_64 system. I did the following:
- sudo pacman -Syu [this did not update playonlinux or any of its dependencies]
- sudo pacman -R playonlinux
- <download playonlinux-git tarball from AUR and cd to the directory where it's extracted>
- makepkg
- sudo pacman -U ./playonlinux-git-1\:4.2.5.r33.gf6102a6-1-any.pkg.tar.xz
- <re-instate the default /etc/asound.conf>
- sudo killall pulseaudio [and ensure pulseaudio restarts]
Now I run playonlinux, select a game with a 32-bit wine in the list and open the Wine configuration dialog. When I select the "Audio" tab, I get a crash with the following message:
ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so
wine: Unhandled page fault on execute access to 0x00001ff0 at address 0x1ff0 (thread 0009), starting debugger...
Unhandled exception: page fault on execute access to 0x00001ff0 in 32-bit code (0x00001ff0).
If I re-run the above with a game in a 64-bit wine prefix, then I get a crash again with the following message (note the line about wrong ELF class):
err:module:load_builtin_dll failed to load .so lib for builtin L"winemp3.acm": libmpg123.so.0: wrong ELF class: ELFCLASS64
ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
wine: Unhandled page fault on read access to 0x00002ab0 at address 0x2ab0 (thread 0024), starting debugger...
Unhandled exception: page fault on read access to 0x00002ab0 in 64-bit code (0x0000000000002ab0).
Looking at the note about wrong ELF class, I installed lib32-mpg123 and re-ran the test, getting a crash with the following message:
ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
wine: Unhandled page fault on read access to 0x00002ab0 at address 0x2ab0 (thread 0024), starting debugger...
Unhandled exception: page fault on read access to 0x00002ab0 in 64-bit code (0x0000000000002ab0).
If I remove /etc/asound.conf and re-run the above tests, then I get no crash. If I run the above tests manually (i.e. invoke the appropriate (32 or 64 bit) winecfg from the command line instead of through playonlinux) with /etc/asound.conf, then I get no crash.
So I'm stumped. Is playonlinux looking for a 32-bit libmpg123 even when running a 64-bit wine? And even when it finds one, it still crashes if /etc/asound.conf exists.
EDIT: needless to say, both /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so and /usr/lib/alsa-lib/libasound_module_pcm_pulse.so exist on my system, so I wonder why ALSA can't open them.
]]>It works, I'd argue something in PlayOnLinux's build environment leading to this break, as I mentioned earlier in this thread it works with own builds and with PoLs 64bit builds for some reason.
Can you confirm PA 5.0 works with playonlinux-git from the AUR?
]]>It is somewhat impossible for no breakage to occur, ALSA programs will only be able to access the soundcard if pulse isn't playing anything and vice versa.
Agreed, and I mentioned this in post #60. However, in my case it was a choice between two breakages: non-working headphones with the .asoundrc method, vs. inablilty for simultaneous ALSA and pulseaudio audio playback with the asound.conf method; I chose thse second breakage.
Digging around a bit on Google I find that Wine has been arguing about having native pulseaudio support since 2007 (!) (see https://bugs.winehq.org/show_bug.cgi?id=10495 ). Wine's Wiki (http://wiki.winehq.org/Sound) recommends using pulseaudio's built in ALSA compatibility layer (and even then, they only say that it "should work"), but it appears from my (and others') experience that this does not always work.
]]>You will break less stuff if instead of deleting /etc/asound.conf you use winecfg and configure wine to access the soundcard directly.
Tried that too Winecfg crashes on selecting the "Audio" tab if I have /etc/asound.conf. The funny thing is though, this seems to be a playonlinux problem; if I run winecfg via playonlinux, then I get a crash, but running winecfg from the command line seems to work. This is not a solution for me though, since I like the convenience that playonlinux offers of managing wine versions per game.
Anyway, I've been running Ubuntu without an asound.conf (which is how Ubuntu stock ships) for about a year now with no problems; let's see how long I last on Arch No breakages for me so far with an up-to-date Arch system, but of course your milage may vary.
]]>