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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from oiaohm at gmail.com 2012-06-01 21:05:42 PDT ---
Tanu Kaskinen
"pasuspender bash
    wine --audio=alsa:device=sysdefault program.exe"
--audio is not a flag wine responds to.

--audio=alsa:device=sysdefault  it will try to run
--audio=alsa:device=sysdefault.exe in most versions.

Really you have not tried this.  Its functionally not possible to use this
solution with the way wine works.

Wine running programs calls multi executables so must be a long term setting
there is no valid option command line to alter wine behaviours.  So wine
program running a new sub program runs a fresh loader.  This would mean
regenerating command-lines and other nightmares leading to command lines too
long.

Due to this the only audio overrides are environment variables or registry that
people can also leave set.  This is the problem there is no setting with wine
that is locked 100 percent for 1 run.  Officially there is no wine
environmental var key to alter audio.  Since registry alignment for settings
will also be required in places as well to match the new audio setting.

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

In fact you are.  Because there is no 100 percent sure way to temp set.  There
will never be 100 percent temp way to set with wine.

Reality wine will break pulseaudio if we follow your instructions.  This is not
avoidable.

Tanu Kaskinen 
"OOM killer should print "pulseaudio invoked oom-killer" to the kernel log if
your theory is correct. Have you checked that?"
See applicaiton running in wine pulseaudio and many other things with miss
behaving programs in wine setting off oom-killer.  But it is less when using
dmix.

Tanu Kaskinen
"I have hard time believing that applications are able to get away with
consuming all memory on Windows."
To be correct they don't.  Issue is Linux allows over allocation windows does
not.  Lets say hello trouble.   Wine can and does at times create full chaos.

Yes there are reasons why we are looking to cgroups to enforce a few things.

So yes running next to wine you have to expect when things go wrong oomkiller
is going to be triggered.

With the mixing
http://www.alsa-project.org/main/index.php/Asoundrc
Then you look at alsa-base all the defined cards.  Yes automatically on any
card without mixing default has dmix or equal added.  default always works and
always has mixing all bar one case pasuspender.

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

Yet when user tries to send audio to default in suspended state this errors. 
User should not have todo extra instructions.  Extra instructions cause user
error.

For wine to be safe we need default to work.  By alsa default should work.

If you cannot disconnect the pulseaudio plugin can you not make it auto forward
to sysdefault when suspended  Yes will add some lag but safer since it removes
wine having to set setting in it that can stick.  Lot of cases we suspect it
wine doing things the sound server part of pulseaudio does not like.

Basically wine need the behaviour of default working.  Default broken wine
believes sound broken.  This is a very valid presume.

So to wine people pasuspender is simply busted.  Because real alsa not having a
working default is busted.

Tanu Kaskinen
"Alsa applications have to be explicitly told to use some other device than
"default" when using pasuspender. I don't see that ever changing."
This is not Alsa this is a Pulseaudio hack.  Because you have not provide a
solution to provide a proper working alsa configuration.

Wine will just keep on using sysdefault when it should not be and breaking
pulseaudio.   Reality wine is limited on what it can change.   Wine requires
something global to refer to for audio settings.  That is not being set right
so leading to big problems.

Your complete idea of what applications can do is wrong.  Wine cannot set
proper temp setting for audio.  This will never change.  Wine to be safe really
needs the globals set correctly.

So the recommendation to remove pulseaudio is right.  There is a fault you will
not fix that will forever cause wine trouble.

Does not help that a lot of people using pulseaudio have the wrong idea what
pasuspender does.  Lot have the wrong idea it gets them back to raw alsa
without pulseaudio.  Not that its a hack.  They come to winehq channel all the
time on irc saying they tested with and without pulseaudio.  Guess what they
tested with pulseaudio enabled and with pasuspender not without pulseaudio.

So even that the program works perfectly on alsa and due to some bad behavours
upsetting pulseaudio they come it us like is fully broken.

Really for wine either fix pcm.default in pasuspender or remove it completely
from pulseaudio so you are not driving the wine support channel up wall any
more.  If you remove it completely the recommendation to remove pulseaudio will
remain.

Fix pcm.default will open the possibility of wine and pulseaudio working with
each other.  This is a case wine cannot alter to suit you.  Lot of alterations
over the years have been added to the wine alsa driver to suit pulseaudio.

Making default always work one way or the other cannot be too hard.

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