Re: Wine and PulseAudio 5.0

@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

Re: Wine and PulseAudio 5.0

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

Re: Wine and PulseAudio 5.0

Re: Wine and PulseAudio 5.0

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.

Re: Wine and PulseAudio 5.0

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.

Re: Wine and PulseAudio 5.0

ceri wrote:

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).

Re: Wine and PulseAudio 5.0

R00KIE wrote:

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.

Re: Wine and PulseAudio 5.0

V1del wrote:

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.

Re: Wine and PulseAudio 5.0

ceri wrote:

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:

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.

Re: Wine and PulseAudio 5.0

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...

Re: Wine and PulseAudio 5.0

V1del wrote:

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?

Re: Wine and PulseAudio 5.0

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

Re: Wine and PulseAudio 5.0

V1del wrote:

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.

Re: Wine and PulseAudio 5.0

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:

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.

Re: Wine and PulseAudio 5.0

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.