I've found pulseaudio patches on wine bug tracker
and people says patches work good.
so, add please these patches into wine package.
at least optionally
Steps to Reproduce:
Well, depending on your setup,
pulseaudio may work out-of-the-box with wine.
(In reply to comment #1)
> Well, depending on your setup,
> pulseaudio may work out-of-the-box with wine.
that's the reason why not make it native? (not through alsa)
I've been applying Art Taylor's pulseaudio patches for quite some time now with great success. Alsa and OSS don't work for me in many applications in wine (crashes, choppy audio, etc.). Only the native pulseaudio driver works well. I certainly vote for a "pulseaudio" USE flag that applies these patches.
Remember, one of the patches modifies the configure script, so the ebuild would have to call autoreconf after applying the patches.
These patches will not build on amd64 unless 32-bit pulseaudio libraries are installed. (Bug #186820)
there's a whole lot of noise/flak on that report i dont want to touch
you can download the patches and put them into:
and then they should get applied automatically when you emerge wine
(In reply to comment #5)
> there's a whole lot of noise/flak on that report i dont want to touch
yeah.. it seems like a sore spot with the upstream devs
> you can download the patches and put them into:
this won't quite work since the patches change the configure script. Perhaps a compromise would be to add a autoreconf call at the end of src_prepare() so that cases like this are handled? Testing with this, it still doesn't completely work since Art's patches need to be applied with -p1 and epatch_user effectively applies them with -p0, so the new files get created in the wrong places, but adding autoreconf is a step in the right direction.
I found a possible solution:
1) add "autoreconf" to the end of src_prepare() in wine-1.1.31.ebuild
2) combine all of art's patches into one via:
cat winepulse-winecfg-0.6.patch winepulse-0.32-configure.ac.patch winepulse-0.32.patch >/etc/portage/patches/app-emulation/wine/winepulse.patch
I'll see if I can get Art to put this info on his website, but we would still need to add autoreconf to the ebuild. Since this bug has already been closed, I'll open a new bug.
i'm not inclined to add a call to autotools when the normal code does not need it. what you highlight though isnt specific to wine. all packages that apply user patches to autotool source files are going to have this problem. i dont have a solution though to the problem ...
(In reply to comment #8)
> i'm not inclined to add a call to autotools when the normal code does not need
It is true that this code adds a new feature instead of just patching an old one, but I would still call that "normal". What is the down side of adding a call to autoreconf, though? Apart from adding a ~5 second delay to the compilation process, there is no ill effect. In fact, what is the down side to making a call to autoreconf part of epatch_user?
packages now have to depend on autotools, and epatch_user is implicit in all eutils.eclass inherit. not acceptable.
also, i'm pretty sure 5 seconds is awfully under estimated
Created attachment 212295 [details]
wine-1.1.33.ebuild with art's pulseaudio patches included
I wasn't able to find an ebuild anywhere that applies Art's patches http://art.ified.ca/?page_id=40 so I wrote my own for wine-1.1.33 that seems to be working fine tested on ~x86 at least. The ebuild also has a pulseaudio useflag included so you need to add pulseaudio to your /etc/portage/package.use for wine if you want to compile in pulseaudio support. This ebuild should work for any future patches Art releases as well, just change the filenames of the patches in the ebuild when they come out. Refer to http://en.gentoo-wiki.com/wiki/Writing_Ebuilds for creating your local overlay and such if need be.
Created attachment 212306 [details]
wine-1.1.30.ebuild with art's pulseaudio patches included
After a bit more testing I found that under 1.1.33 the sound would cut out after a few minutes of gameplay and was also having maybe unrelated issues with another app with 1.1.33 so I went back to 1.1.30 which is what I used before and rewrote that ebuild instead. The ebuild varies slightly and I had to use the respective patches for 1.1.30 from Art, (winepulse-0.30 patches), you can see them in the ebuild. Anyways this one seems to work flawlessly so far after a couple hours of testing.
Created attachment 216223 [details, diff]
updated patch for configure.ac wine 1.1.30
thought i would go ahead and post an updated patch file so that other people could avoid the problems that i myself experienced when trying to use the previously posted ebuild with the latest patches from arts page. hope it works as well for everyone else as it did for me, no hiccups yet at all with wine and pulseaudio output!
*** Bug 305675 has been marked as a duplicate of this bug. ***
just a link to winepulse project from bug report above, since not everyone like to see duplicates
btw current status of this report "RESOLVED UPSTREAM" actually means "WILL BE RESOLVED UPSTREAM ONE DAY" (read article by link above for details)
Yeah, I would reconsider this situation since upstream doesn't want to include it and this is currently needed to get proper sound support with wine+pulseaudio.
What technical changes are preventing its inclusion from Gentoo wine maintainers point of view? Maybe winepulse upstream would be willing to help :-)
Thanks a lot
man power. if upstream is going to significantly drag their heels, i can start including it in the ebuilds ... but as soon as the patches rot, i'll just drop until someone else updates them. i have yet to get pulseaudio to not act like a huge pile of sh*t, so i'm not about to waste time debugging it.
I also don't use pulseaudio yet under Gentoo :-( (but as I could see some time ago in mandriva bugzilla, seemed that pulse patches for wine work ok)
Maybe I could try to contact Stefan Reimer as seems that he's currently maintaining wine ebuilds with pulse plugin in his overlay:
wine-1.1.39 has untested support for USE=pulseaudio
Great, thanks a lot, I know some people will welcome it :-)