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

Sun May 27 18:19:54 PDT 2012

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

--- Comment #6 from oiaohm at gmail.com 2012-05-27 18:19:54 PDT ---
"I thought the use case was comparing, for debug purposes, application behavior
when using pulseaudio and when using direct alsa. In such cases mixing is not
usually needed. pasuspender should never be "the solution" to audio problems
with open source software such as wine. pasuspender is only a debugging tool,
or a workaround for proprietary software that can't be fixed."

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.

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.

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

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.

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.  Only workable options are auto detection or pulseaudio sets default
correct when suspended.  Now if pulseaudio and other sound servers were
returning default to what it should be the hack of sysdefault in alsa could
disappear.   Auto detection would become a hack in the wine alsa driver to work
around the fact pulseaudio is broken in it suspend system.

Its not like using sysdefault is without its own issues if used when pulseaudio
is running.  Like trying to go around pulseaudio succeeding because hardware
has mixing so now fighting with the pulseaudio sound server for access to sound
card leading to very bad sounds generated.

We don't win here.  HW;0 instruction can in fact cause the same problem on some
hardware fine used in suspended pulseaudio state but you don't want someone
trying that when pulseaudio is running sometimes it will lead to disaster.

In fact wine on some systems is breaking pulseaudio because wine is trying
sysdefault first at times and when it does not fail processed to uses it while
pulseaudio is running so bringing house down.

The idea of pasuspender you have stuffed up.  You have presumed incorrectly
that programs that will have trouble with pulseaudio are after direct hardware
access.  Not that they are after a system with a fully working alsa setup.

Yes to compare driver operations wine needs to see a fully working alsa setup
and a fully working pulseaudio one.   This way we can compare error messages. 
and possibly work out where the system went wrong. 

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.

I know fixing the alsa default to point in the right place is not simple.  But
telling people to use direct hardware or sysdefault is not good solution.  Yes
wine we are already seeing problems from both.  Due to the breakages this is
why the recommendation remove pulseaudio exists if you want to run wine.

I wish not to have to provide recommendations to remove pulseaudio.  It does
many thing well.  But one key thing it does poorly is suspend.  This is not a
new issue all sound servers have this issue so most likely something in alsa
has to be corrected to allow it.

In fact if you work out how to change alsa configurations on the fly you can
prevent all tunnelling under pulseaudio when running.  Why you cannot access
something when its interface is not displayed.

Lacking the means to change configuration on fly causes 2 issues.  One
pasuspender makes people do unsafe things.  Two pulseaudio can be tunnelled
under by a alsa application causing problems because people are doing those
unsafe things when pulseaudio is running.  Wine does not want to be tunnelling
under pulseaudio and being blamed for breaking it either.

Now a cgroup control of alsa around applications going to pulseaudio blocking
those applications from seeing all hardware interfaces other than pulseaudio
nicely kills a set of problems.  Then another cgroup for applications going
straight to hardware.  Now the more interesting question then is can a cgroup
suspend be used on the applications going straight to hardware to allow a
critical audio message from a pulseaudio application to be played.

Basically done correctly alsa direct using alsa applications might be just as
suspend-able as pulseaudio using applications.

All wine wants is alsa audio interfaces that work correctly that will not allow
wine to ruin user experiences and allows wine to test what it needs to in
comparative testing.  Really it should not be asking too much.  Better control
over what alsa application see will prevent them from doing bad things to
pulseaudio.

Pulseaudio people think of alsa as low level.  Alsa should be thought of as
generic interface that should work if its basic rules are obeyed.  Problem here
is no sound server has made sure they can provide working alsa configurations
in every combination.  pcm.default does not play sound and mix is a broken for
any alsa driver setup.  That is what happens under pasuspender so alsa in that
mode is broken.

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