[pulseaudio-tickets] [Bug 50256] pasuspender alsa hook test fix.

Tue May 29 01:16:22 PDT 2012

https://bugs.freedesktop.org/show_bug.cgi?id=50256

--- Comment #7 from Tanu Kaskinen <tanuk at iki.fi> 2012-05-29 01:16:22 PDT ---
(In reply to comment #6)
> That is the problem you debugging case is wrong.  For wine to debug we need
> perfered to see as if pulseaudio never touched alsa.
> 
> Even with dmix and alsa we are very suspect that this avoid a issue.  We cannot
> get enough testing to fully prove it because people want there game to work now
> with the least editing of stuff.  Simple problem is wine is heavy at times.  We
> suspect wine ends up hogging the cpu time and ram in multi small processes with
> a low OOM Killer preference so basically pushing Pulseaudio into being killed
> by kernel.  So pulseaudio screws up due to resource starvation caused by way
> some programs run in wine.  Basically Pulseaudio killed because its a sound
> server.   Now this would become very clear if Pulseaudio is disabled and the
> kernel kills it.  If this is the case Pulseaudio working with wine without
> better process control is impossible.   This behaviour of wine to pushing audio
> servers under the pre-verbal bus not new.  Result might be Pulseaudio with wine
> limited to systems with systemd and ulatencyd so wine cannot push sound server
> into the OOM Killer as the only existing safe way to run the combination.

OOM killer should print "pulseaudio invoked oom-killer" to the kernel log if
your theory is correct. Have you checked that?

> Just to be clear it is the "proprietary software" in wine that causes wine to
> open so many sub processes at times.  This is not something wine can change. 
> So not fixable from the wine side.  This is something you doing pulseaudio are
> not considering wine will at times have evil tendencies to resource usage
> because windows programs are use to getting away with it.  So not all breaks of
> pulseaudio will track to audio output of wine.  Some with just track to wine
> being wine and resource management in the distribution not being up to it.  We
> do need to be able to prove this as well perfered without having to tell users
> to uninstall pulseaudio.

I have hard time believing that applications are able to get away with
consuming all memory on Windows.

> "In any case, feel free to replace hw:0 in my example with sysdefault, if the
> lack of mixing is a problem when debugging. Are "sysdefault's" semantics
> defined somewhere, btw? It's not documented at [1] at least. I doubt that it
> actually guarantees anything about mixing - my guess would be that "sysdefault"
> just happens to be usually be defined as card 0 with dmix, and therefore it
> usually also supports mixing."
> 
> sysdefault is define as what alsa would have setup as default if pulseaudio and
> nothing else had touched it.  This is in the source.
> 
> Default under alsa is define as having mixing or the card configuration is
> defective.  So yes its look up alsa define for default then see that sysdefault
> is just a non tampered with version.  So wine is able to work with this.  Where
> sending it straight to hardware does not work.  So sorry it is defined.
> 
> Sysdefault is a hack in alsa added to work around the fact the pasuspender and
> other sound servers when suspended have the defect of leaving default a non
> operational state.

Can you point to some documentation?

> Wine is based on the fact default works unless the alsa card config is
> defective.
> 
> This is where pasuspender becomes a problem.  The default you expose is
> basically disabled and at times broken.  Throwing back error that sound card is
> non functional because pulseaudio is disabled.  So basically creating a
> defective alsa state that is not meant to exist and is confusing to
> applications.

You seem to want to make pasuspender a switcher between "fully functional
system with pulseaudio" and "fully functional system without pulseaudio".
That's not going to happen. There would be more involved in that than just what
the definition of the "default" device is. Implementing all that is not the
purpose of pasuspender. Alsa applications have to be explicitly told to use
some other device than "default" when using pasuspender. I don't see that ever
changing.

> Problem comes in that wine is just like running a http server.  It can fork
> parts off and lose track of them so blocking pulseaudio from being able to
> leave suspend this most likely will require a cgroup solution or equal done
> somewhere.
> 
> You have presumed that testing can be done by skilled people.  With item like
> wine we cannot afford todo this its just budget impossible.  Since the skilled
> people cannot afford to buy all the software to test it.
> 
> With wine not all out testers are skilled so we do need to be able to give them
> simple instructions.  Like pasuspender wine <run your program>. Currently this
> cannot work.  So command line options or alter registry manually is not a valid
> options.

Really? Typing

    pasuspender wine program.exe

to a terminal is ok, but typing

    pasuspender bash
    wine --audio=alsa:device=sysdefault program.exe

is too hard?

> Basically to prevent wine breaking pulseaudio you need wine to be able to use
> default dependably.  So you can be sure that wine will not try to tunnel under
> pulseaudio by some means when it should not.  Same with other applications you
> don't want to say hey use HW:0 or use sysdefault were possible due to the fact
> of where you are leading these applications.  You are leading them to breaking
> the audio system even worse to more driver issues.

No, I'm not encouraging applications to use "hw:0" or "sysdefault".
Applications, including wine, should always use "default", unless the user
instructs them to do otherwise.

User may need to instruct the application to use e.g. "sysdefault", but ONLY
when debugging a problem. Using "sysdefault" or "hw:0" should never be the
solution, it's only an intermediate step while trying to figure out what the
problem is.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.