Last Wine 1.1.10/11 = pulse sound stuttering

psychok9 · Post by **psychok9** » Sun Dec 28, 2008 8:30 pm

With last Wine & World of Warcraft the sound stutters.
With last from Ubuntu repository (old) 1.0.1, work near the flawless!
I use alsa (pulseaudio -> default -> alsa).
... But sometime World of Warcraft crash.
Now I've tried 1.1.10 and 1.1.11 (1.1.11 is compiled from myself) and the the sound stutters.
Please fix this problem

Ubuntu 8.10 x86_64
[email protected]
X-Meridian 7.1
nVidia 8800 GT 512Mb Zotac AMP!

p.s. With padsp & Virtual OSS work... but pulse crash often on long game session (nosound -> console -> and i type pulseaudio for get back the sound).

James McKenzie · Post by **James McKenzie** » Sun Dec 28, 2008 8:48 pm

psychok9 wrote:

With last Wine the sound stutters.
With last from Ubuntu repository (old) 1.0.1, work near the flawless!
I use alsa (pulseaudio -> default -> alsa).
... But sometime wow crash.
Now I've tried 1.1.10 and 1.1.11 and the the sound stutters.
Please fix this problem

Ubuntu 8.10 x86_64
[email protected]
X-Meridian 7.1
nVidia 8800 GT 512Mb Zotac AMP!

Sad to say, but there are no official efforts to support PulseAudio.

You will have to disable it and enable ALSA or OSS.

James McKenzie

psychok9 · Post by **psychok9** » Sun Dec 28, 2008 9:06 pm

I use pulseaudio for great audio software mixing (often I play with music on background)... and I don't understand how can work flawless with 1.0.1 and broken with 1.1.11.

I get a new crash just after my post... nVidia 180.18 driver.
When 1.10.11 don't seem fix crashs problems.
Can I map only 3Gb of my memory only on Wine?

Code: Select all

Dalaran and/or other areas cause crashes

This is due to WoW running 32-bit (there is no 64-bit client) and trying to allocate more than roughly 4GB of memory for advanced textures. This is a bug in Wine, since wine, by default, reserves 4096MB (the maximum for 32bit systems) of virtual memory to mimic the win32 memory layout. WoW allocates progressively more memory for textures and this forces the display drivers (which are loaded in the same section of memory) to quit with an GL_OUT_OF_MEMORY error.

Dalaran is a good example of this. Dragonblight and Icecrown may also suffer from this bug.

A possible workaround includes trying is to force Linux to use less memory than what you have, or to make it think it has less memory (eg, limit it to 3GB). The preferred way to do this is to add the mem=3072 (for 3GB) or mem=2048 (For 2GB) flag to your kernel boot parameters.

How to do this can be found in your particular distro's documentation.

Some people have reported it to work, whilst for others it has not. You may need to sacrifice the advanced textures if you try this.

psychok9 · Post by **psychok9** » Sun Dec 28, 2008 9:12 pm

Solved!
Driver emulation flag on winecfg fix my problem!

This option slow seriously my wow performance?
Thank you!

jeffz · Post by **jeffz** » Sun Dec 28, 2008 9:30 pm

James McKenzie wrote:psychok9 wrote:
With last Wine the sound stutters.
With last from Ubuntu repository (old) 1.0.1, work near the flawless!
I use alsa (pulseaudio -> default -> alsa).
... But sometime wow crash.
Now I've tried 1.1.10 and 1.1.11 and the the sound stutters.
Please fix this problem

Ubuntu 8.10 x86_64
[email protected]
X-Meridian 7.1
nVidia 8800 GT 512Mb Zotac AMP!

Sad to say, but there are no official efforts to support PulseAudio.

You will have to disable it and enable ALSA or OSS.

James McKenzie

This is not true. There are active efforts to fix PulseAudio issues.

psychok9 · Post by **psychok9** » Sun Dec 28, 2008 9:46 pm

jeffz wrote:This is not true. There are active efforts to fix PulseAudio issues.

Great news! Can you answer my performance question? If you know it

...and sorry for my english

jeffz · Post by **jeffz** » Sun Dec 28, 2008 10:07 pm

psychok9 wrote:
jeffz wrote:This is not true. There are active efforts to fix PulseAudio issues.
Great news! Can you answer my performance question? If you know it

...and sorry for my english

The stutter problem is known (bug 16607) either go back to 1.1.10 or wait for the problem to be fixed.

Marcel W. Wysocki · Post by **Marcel W. Wysocki** » Mon Dec 29, 2008 3:28 am

On Sun, 28 Dec 2008 20:30:41 -0600
"jeffz" <[email protected]> wrote:

This is not true. There are active efforts to fix PulseAudio issues.

IMO the only sane effort to fix it would be to make the wine package conflict
with the pulseaudio package

--
Marcel W. Wysocki <[email protected]>

msclrhd · Post by **msclrhd** » Mon Dec 29, 2008 3:37 am

Hi, for all pulseaudio issues to be fixed - as far as I know (see bug 15559), you need the latest git (i.e. post 1.1.11) to pull in my fix. This needs the patch in bug 1607 to correct an issue with that patch. After that, sound should be good.

oiaohm · Post by **oiaohm** » Mon Dec 29, 2008 7:28 am

Be aware that 1.1.x line is development line so defects do happen. 1.0.1 includes a pulseaudio patch.

"With padsp & Virtual OSS work... but pulse crash often on long game session (nosound -> console -> and i type pulseaudio for get back the sound)."

That failure is not wine related. That is a pulse internal defect. So I would recommend disabling pulseaudio completely.

Also be aware if your card has hardware sound mixing you are for sure better off without pulseaudio reason pulseaudio uses your cpu for audio mixing that take cpu time away from your game.

Also dmix from alsa is also lighter on cpu usage. Yes less features. I prefer less features and my games running stable than most features and glitches due to internal defects in pulseaudio.

Not exactly on the 3gb map issue. Another work around is to use a Linux cgroup to limit the memory wine sees so you can use all of memory normally. Issue here is a funny one. Wine says 4 gb to application wow does not know how to handle it. Something wow users miss enable PAE mode on there Windows XP and it will spit chips the same way. PAE mode allowed 4 gb of user space and kernel space of 32 bit windows in a different memory zone. Yes also allow 32 bit windows xp to take advantage of 8 gb or ram or more.

There is a reason why Wow is not designed for PAE mode a lot of Windows drivers also spit chips in PAE mode.

Basically tell wow it has 4 gb of ram to use it goes nuts and trys to allocate more than that. Yes 4096MB is not the max for a 32 bit system. Max for a 32 bit system with PAE enabled is 64 GB.

psychok9 · Post by **psychok9** » Mon Dec 29, 2008 10:18 am

oiaohm wrote:Be aware that 1.1.x line is development line so defects do happen. 1.0.1 includes a pulseaudio patch.

Can I download a patch for 1.1.x?

That failure is not wine related. That is a pulse internal defect. So I would recommend disabling pulseaudio completely.

With pulseaudio I got, also, the 6 channel mixing on the fly, 2 or 6 channel source...
...and I don't remember if Alsa support many play at the same moment.

Also be aware if your card has hardware sound mixing you are for sure better off without pulseaudio reason pulseaudio uses your cpu for audio mixing that take cpu time away from your game.

Also dmix from alsa is also lighter on cpu usage. Yes less features. I prefer less features and my games running stable than most features and glitches due to internal defects in pulseaudio.

I understood your point of view... but Linux support hardware acceleration? If with alsa (& Linux), the support is only software... the difference it should minimal.
How can I verify hardware channel mixing support?
I remember this "dmix" on winecfg alsa panel... on a old version of Ubuntu... It's software mixing?

Not exactly on the 3gb map issue. Another work around is to use a Linux cgroup to limit the memory wine sees so you can use all of memory normally.

You know how can I setup it?

Thank you very much for your kindness

p.s. Can I disable (soft) temporally pulse-audio on startup auto-script without uninstall it?

psychok9 · Post by **psychok9** » Mon Dec 29, 2008 10:34 am

msclrhd wrote:Hi, for all pulseaudio issues to be fixed - as far as I know (see bug 15559), you need the latest git (i.e. post 1.1.11) to pull in my fix. This needs the patch in bug 1607 to correct an issue with that patch. After that, sound should be good.

Thank you! I'll find it.

oiaohm · Post by **oiaohm** » Mon Dec 29, 2008 7:03 pm

bug 15559 repairs the pulseaudio patch the 1.1.10 broke. Yes development tree these kinds of breaks are to be expected. Patches are in the development tree because they need testing.

Difference between pulseaudio and dmix is fairly major.

Adding per application volume controls ands a extra level of mixing and altering.

dmix there is the application sound output buffers and output buffer to sound card and quite simple transformations between most complex dmix alteration is a bit width alteration.

Pulseaudio there is application sound output buffers these are then mixed to a intermittent buffer then applications volume control alteration and other alterations applied then finally passed on to card for output.

From a cpu usage point of view Pulseaudio is at least 4 times heavier than dmix. That is before you enable stuff like 6 channel virtual sound card being output on 2 channel.

You are paying a price for it.

Yes if your sound card has a onboard mixer alsa supports hardware acceleration of audio mixing there will be almost no cpu load at all.

Soft disabling pulseaudio also nastly fails on non hardware mixing cards. No matter how much I have asked the developer of pulseaudio to enable auto starting of dmix or a warning that no mixing is provided he has flatly refused to do either. So effectively left with a crippled audio setup if your card does not have hardware audio mixing. Yes Ubuntu has made it extremely hard to use the lightest audio setup.

http://lwn.net/Articles/268937/ << Hopefully Ubuntu build with cgroup in kernel. Thinking in newer Linux kernel you have to go out of your way to disable it. When building kernel from source graphical configuration don't even give you the option to disable it. Since its classed as kinda key feature.

Cgroups can do a lot more than just memory control they can also control what devices a application can access, network access what percentage and ammount of cpu time applications get. Really useful tool for misbehaving programs.

Thing most people are not aware is that all processes in kernels with cgroups enabled are always running in a cgroup. The default cgroup. Any process that a application starts remains in the cgroup the application that started it is in unless assigned else where.

Becareful with them very powerful tool. Highly useful. Controlling cgroups is one time where running as root/admin is kinda required. Knowing the process id of a normal users shell allows that to be transfered into cgroup to run wine. echo $$ will tell you the PID of current bash.

psychok9 · Post by **psychok9** » Wed Dec 31, 2008 10:14 am

Last Wine source 1.1.11 compiled & installed.
I still have game crash, but the sound works again correctly!

DL · Post by DL » Wed Dec 31, 2008 10:03 pm

oiaohm wrote:http://lwn.net/Articles/268937/ << Hopefully Ubuntu build with cgroup in kernel. Thinking in newer Linux kernel you have to go out of your way to disable it. When building kernel from source graphical configuration don't even give you the option to disable it. Since its classed as kinda key feature.

Cgroups can do a lot more than just memory control they can also control what devices a application can access, network access what percentage and ammount of cpu time applications get. Really useful tool for misbehaving programs.

Thing most people are not aware is that all processes in kernels with cgroups enabled are always running in a cgroup. The default cgroup. Any process that a application starts remains in the cgroup the application that started it is in unless assigned else where.

Becareful with them very powerful tool. Highly useful. Controlling cgroups is one time where running as root/admin is kinda required. Knowing the process id of a normal users shell allows that to be transfered into cgroup to run wine. echo $$ will tell you the PID of current bash.

When you suggested using cgroups as a workaround, were you referring to these bugs? :
http://bugs.winehq.org/show_bug.cgi?id=13335
http://bugs.winehq.org/show_bug.cgi?id=10778

Because I tried it, but could only get to it to limit RSS memory (which doens't solve the problem) not VIRT memory, which still grows to 4096mb and greater, even with much lower RSS limits (I tried down to 512MB)

oiaohm · Post by **oiaohm** » Wed Dec 31, 2008 10:59 pm

If setting mem=XXXX in kernel startup fixes the problem so should cgroup with memory.limit_in_bytes. They are both in 2.6.28 ment to control the same thing. Some older kernels you have to set memory.control_type if it exists in you cgroup folders you have it set it sorry I cannot remember the setting to cover RSS(mapped) and Page Cache(unmapped) at the same time. Should be the only factor of difference from mem=.

Now if its not setable the same as mem= we have a glitch in cgroup.

Now virtual memory is another issue. It going out of control has a different way of handling it.

My kernel 2.6.28 cgroup manages RSS (mapped) and Page Cache (unmapped). Not swap cache and virtual memory . Now this opens a interesting question tried disabling virtual memory. http://www.ss64.com/bash/ulimit.html ulimit on the process option -v. Yes value 0 for testing flat out disallow virtual memory usage. Then latter allow the application a sane amount. Basically application could be a greedy pig of an application only stops allocating when it gets told there is no more memory.

-v 0 setting from ulimit is the same as not having any virtual memory. No virtual memory equals no run.

Virtual memory going insane also happens in some native Linux programs.

What ever you set in ulimit applies to all applications run in that shell after that until its changed. Bewared only root on some systems has the right to re expand a ulimit after its set. I don't think wine messes with ulimit directly itself.

Opps sorry tired. ulimit -v 1048576 is more sane. Max of 1 gb of memory. You could expand that to 2 to 3 gb no problems. That is a per application limit.

psychok9 · Post by **psychok9** » Thu Jan 01, 2009 3:46 pm

I don't understand how cgroup work...
I've tried ulimit -v 1048576 and after launch winecfg but don't work.

oiaohm · Post by **oiaohm** » Fri Jan 02, 2009 12:12 am

Sorry I forget wine must have around 4GB. I gave instructions based on how to deal with normal programs under Linux being hogs using ulimit.

Now of course more than 4GB equals problems for some problems. Bare min ulimit I have found to get winecfg to kick up is ulimit -v 3707585. So a ulimits between 3707585 to 4194304 would be recommend range. Note going for the high side would be better than going too low.

Thinking ulimit virtual memory limit when hit causes to wine to respond with Cannot allocate memory. Should not break well coded applications instead trigger them to release memory and reuse.

For some of those memory bugs trying ulimit would be highly recommended. It might be all that is required to prevent.

cgroup is a virtual filesystem that is not mounted by default. Simplest way its to put a shell in the limited cgroup and use it to run stuff limited. Basically if mem= works for problem then going to cgroup is the correct way. Even so there is a chance that ulimit -v could also prevent them as well.

Linux does have lot of good memory control features.

Das Letzte Einhorn · Post by **Das Letzte Einhorn** » Fri Jan 02, 2009 9:45 am

If you are willing to test WINE-Pulse development..

http://art.ified.ca/?page_id=40

oiaohm · Post by **oiaohm** » Fri Jan 02, 2009 8:05 pm

You are asking for special treatment. Main line wine developers will never accept it that patch. Using that patch means people like me will no longer provide support to anyone using it.

Major problems its not done as a git patch that will make sure that merging will not conflict leading to worse problems than what you have now with pulse. Yes person does not even give tested git versions the patch matches up to. Developer is incompetent and it shows. So don't touch.

http://sourceforge.net/projects/wineasio is done right. Its a third party audio interface not integrating into wine build systems not risking causing house to fall in. Wine can take third party audio interfaces. No messing with git trees or anything else just a stand alone module with registry registrations. Using third party interfaces like wineasio does basically void our responsibility to help you as well. But since its constructed right we will look past it until we have evidence that its cause. Most likely ask you to disable it and try a different audio interface.

If Pulseaudio alsa interface does not work its there problem. If they did not push them-selfs as a replacement to dmix an alsa part it would be different.

Compiz asked for the same special treatment. Flat refusal is policy to create patches to hide error. OSS and ALSA interfaces Pulseaudio is ment to be able to handle so we are already providing them with 2 chances to get it right.

psychok9 · Post by **psychok9** » Sun Jan 04, 2009 11:34 am

With latest builds the sound work perfectly (standard fake alsa -> Pulse -> alsa -> card).

I've tried to compile wine + pulse audio patch but don't work (works without patch).
I'll try wineasio.

But with the tip of oiaohm I've fixed the crash problems!
With mem=3G on boot kernel menu, Linux see only 3Gbyte of my RAM... and Wine + WOW don't crash anymore...
How can I signal this bug to Wine team?

austin987 · Post by **austin987** » Sun Jan 04, 2009 12:40 pm

On Sun, Jan 4, 2009 at 10:34 AM, psychok9 <[email protected]> wrote:

With latest builds or emulation acativated the sound work perfectly (standard fake alsa -> Pulse -> alsa -> card).

I've tried to compile wine + pulse audio patch but don't work (work without patch).
I'll try wineasio.

But with the tip of oiaohm I've fixed the crash problems!
With mem=3G, Linux see only 3Gbyte of my RAM... and Wine + WOW don't crash anymore...
How can I signal this bug to Wine team?

Please don't file bugs related to PulseAudio, send those to
PulseAudio/Ubuntu instead.

For _actual_ wine bugs:
http://bugs.winehq.org/

--
-Austin

James McKenzie · Post by **James McKenzie** » Sun Jan 04, 2009 6:59 pm

Austin English wrote:

On Sun, Jan 4, 2009 at 10:34 AM, psychok9 <[email protected]> wrote:

With latest builds or emulation acativated the sound work perfectly (standard fake alsa -> Pulse -> alsa -> card).

I've tried to compile wine + pulse audio patch but don't work (work without patch).
I'll try wineasio.

But with the tip of oiaohm I've fixed the crash problems!
With mem=3G, Linux see only 3Gbyte of my RAM... and Wine + WOW don't crash anymore...
How can I signal this bug to Wine team?

There should already be a bug related to the max memory size of 3GB.

As to the PulseAudio problems, there may be a few bugs in Wine's
Bugzilla, but there are no plans to repair them nor any plans according
to concensus to fix any of them. Recommend moving to ALSA or OSS for
your audio needs.

James McKenzie

psychok9 · Post by **psychok9** » Wed Jan 07, 2009 9:37 pm

oiaohm wrote:Sorry I forget wine must have around 4GB. I gave instructions based on how to deal with normal programs under Linux being hogs using ulimit.

Now of course more than 4GB equals problems for some problems. Bare min ulimit I have found to get winecfg to kick up is ulimit -v 3707585. So a ulimits between 3707585 to 4194304 would be recommend range. Note going for the high side would be better than going too low.

Thinking ulimit virtual memory limit when hit causes to wine to respond with Cannot allocate memory. Should not break well coded applications instead trigger them to release memory and reuse.

For some of those memory bugs trying ulimit would be highly recommended. It might be all that is required to prevent.

Thanks.
I've tried ulimit -m 3145728 with no results but with -v 3145728 Wine don't start. 3707585 same. Can fix it I only with the setup the kernel and Linux for only 3Gbyte of memory? Or Wine will fix the bug in the future?

oiaohm · Post by **oiaohm** » Thu Jan 08, 2009 5:50 pm

3707585 is the low side works with my form of wine most likely the complier I used built wine smaller. Try -v 4194304 I think the issue may not be 3Gbyte alone. Because once you go over 4194304 the pointer to the memory location no longer fits in a 32 bit number.

Ok Linux kernel set to 3Gbyte of memory will still give almost unlimited virtual memory on 64 bit systems. Ok unlimited to what windows applications are use to. 32 gb worth per 32 bit application.

Now I don't know exactly what wine is telling the application. mem=3g as a kernel switch or using cgroup changes the amount of physical ram that can be see to be existing by an application. Issue here might need using both side by side. One to restrict virtual memory to the same limits as windows and one to lie about how much ram you have installed in your machine.

mem=3g and cgroup change only will do something if you have more than 3g of physical ram in the machine.

Part of working out the bug is working out what area the bug is in. Is it phyisical memory detection or is it Virtual memory. Or is it both. Or most annoying case neither wine.

Yes we have two different bugs that give almost the same effect now what one is your program.