You are not logged in.
ceri: I'm working on improvements to the ALSA driver in Wine to fix this. Don't hold your breath, but it is being worked on in Wine.
Offline
@ColdPie: This thread mixes way too many unrelated problems, I doubt any improvements you make will (albeit sounding pretty exciting ) make PoL with PA 5 recognize the system lib32-alsa-plugin in a 32bit-prefix, which was the original issue and the one ceri searches a solution for
Offline
@ColdPie: Good to hear.
@V1del: I was under the impression that there is only one issue being dealt with in this thread?
Offline
Should post #27 be added to the Wine wiki page? It caused the same problem in Spotify, so I added it there (https://wiki.archlinux.org/index.php/Sp … _client.29), but it seems a bit redundant as it is a common Wine problem.
Last edited by torpet (2014-05-01 21:39:43)
Offline
Well playing with fragment values to fix issues is in the PulseAudio wiki page and the issue is not wine-specific but buggy alsa drivers in combination with PA 5 and its alsa-plugin. Again this thread originally was crashing of PoL due to it not finding the lib32-alsa-plugin on a 32bit prefix... and then it just grew into general problems that may or may not be related to wine
Offline
I also have this issue (as described by V1del) and it's really frustrating. Seems odd that the file exists in the correct path but is not being loaded.
Offline
I have the same issue. ldd /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so shows http://sprunge.us/jCgV
Offline
I can confirm this prolem. In my case, it goes away by simply removing /etc/asound.conf (installed as part of pulseaudio-alsa). I didn't have to make any of the changes mentioned in the previous posts.
Offline
I can confirm this prolem. In my case, it goes away by simply removing /etc/asound.conf (installed as part of pulseaudio-alsa). I didn't have to make any of the changes mentioned in the previous posts.
Isn't that the equivilent of disabling pulseaudio with ALSA-based apps? That isn't really a fix.
Offline
ashwinm wrote:I can confirm this prolem. In my case, it goes away by simply removing /etc/asound.conf (installed as part of pulseaudio-alsa). I didn't have to make any of the changes mentioned in the previous posts.
Isn't that the equivilent of disabling pulseaudio with ALSA-based apps? That isn't really a fix.
Indeed it is not, it is only a workaround. I guess what it does is it allows ALSA-using programs to grab the ALSA device exclusively, shutting out any programs that may be using pulseaudio at the time (just my guess, I don't know too much about how the whole pulseaudio-ALSA dance happens). However, it does allow me to use both pulseaudio and ALSA, as long as they're not being used together. I can listen to music on my pulseaudio-using music player, and I can play Wine games with audio, but maybe not both together.
I'm not comfortable downgrading packages, so I didn't go that route. And I found that the workaround based on creating ~/.asoundrc resulted in my headphones not working (i.e. the built-in speakers on my laptop work, but when I plug in headphones I get no sound, either from the built-in speakers or from the headphones).
EDIT: I found this workaround by comparing my Arch install with my old Ubuntu install I had on a different partition. Ubuntu seems to use similar default config files for pulseaudio and ALSA as arch, except that Ubuntu does not have /etc/asound.conf. As a result, when I open alsamixer in Ubuntu, I see all the audio devices, whereas when I open alsamixer in the default Arch setup, I see only one device (which I assume is pulse).
Last edited by ashwinm (2014-09-30 05:12:16)
Offline
You will break less stuff if instead of deleting /etc/asound.conf you use winecfg and configure wine to access the soundcard directly.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
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.
Offline
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.
Offline
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.
Offline
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.
Offline
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?
Offline
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.
Last edited by ashwinm (2014-10-02 04:48:16)
Offline
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...
Offline
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?
Offline
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
Offline
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.
Offline
I had this problem. Temporarily solved by compiling and downgrading packages pulseaudio, libpulse & lib32-pulse to version 4.0 (installed from source).
Offline
Okay, this is seriously weird, and only strengthens my theory that pol does some weird shit with their launchers. Indeed launching winecfg from within PoL makes it crash even with a 64bit wine so that doesn't seem to be the culprit. HOWEVER, and this is probably the reason I didn't notice earlier, if you open the wine cmd within pol, and manually navigate to the exe you want to run it will work just fine (with the selected PoL wine version) which is what I did since I didn't have my program located within the wineprefix. This also applies if you write a script which includes all necessary env variables set to their correct values. Here's what I do and this also prevents the first time setup from running which you see if you just switch the prefix:
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
Offline
/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.
Last edited by tachy (2014-11-10 19:52:43)
Offline
To anyone still experiencing the issue of games in POL having no sound in 2017, I have found work-around that's simpler than downgrading libraries.
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.
Last edited by aggregate1166877 (2017-01-06 04:17:15)
Offline