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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #10 from oiaohm at gmail.com 2012-06-04 07:38:18 PDT ---
Tanu Kaskinen
"Why is it impossible to have an environment variable that has only temporary
effect? You say something about "registry alignment" - the windows registry is
something that the applications need to function, but wine's sound backend
setting do not need to be accessible by applications. Is it so that you're
reusing the registry for wine's internal configuration? If that makes it
impossible to alter the internal configuration temporarily with environment
variables, it sounds like a design mistake... Fixing design mistakes may not be
easy, but it doesn't make sense to say that you'll never fix them. Supporting
temporary configuration with environment variables makes sense, and not only
with audio."

This is two problems.
1) Is dealing with new people.    Wine gets a lot of people new to Linux
command line.  So incompetent is not uncommon attempting debugging remotely.

So they do something nasty and evil like "export WINESETTING=<setting>; wine
<program>" instead of "WINESETTING=<setting> wine <program>" the second one is
temporary first one is stuck in environment.

Yes the first results in a value living on after pasuspender would have been
ended to reallow pulseaudio.  So cause us to be yelled at for breaking their
pulseaudio.  So if we were setting a environmental var we need to be sure it
will be cleaned up when suspend ends.  So any extra environment var is a extra
way to drive wine support people up wall if they have to instruct users todo
it.

2) windows applications.  They look up for information on hardware from the
registry yes wine has to show a device id to applications.

There are two different entries in registry one for voice out and one for
general audio out.  Same with input in.  This is required for windows
application compatibility.  So changing on fly would look to application that
you changed sound card.  This can upset some applications.

Wine tries to keep ids displayed to windows applications inside matching to ids
outside wine as much as possible.  Make debugging simpler.

So internal sound output changed to sysdefault from default would cause wine to
change id this is fine as long as we don't have a a picky windows program
inside.  It a extra variable to debugging why is it busted.  Wine has enough
variables without adding any.

Might say don't do this internally but then you have the headache of users who
have changed setting to point to stupid locations not turning up in application
window screen shots.  Yes level of incompetence wine support people have to
deal with its high.  People with less than 8 hours Linux experience turn up in
the wine channel.

"I guess if the user gets the application to work acceptably
with pasuspender or by uninstalling pulseaudio, it may often be hard to
convince the user to help with debugging the problem further..."

If it was working acceptably in pasuspender I would be able to get them to
debug deeper so it works when pulseaudio is running.  Reason user would not
want to stop pulseaudio just to run wine application.  Working acceptably
includes not ending up in a location that ruins everything.

You do have them come now complain run pasuspender I have no sound at all in
wine and give up and remove pulseaudio.  Yes reason is dead simple wine tried
to output to defualt and it does not work.  New users are not always that
tolerant.  Basically I need pasuspender to work without users having to play
with wine.  Play with wine is proven not to result in good outcomes since new
users don't.

Even if users are recording in appdb.winehq.org that this application requires
pasuspender to work we still will get a list of applications to investigate to
find what they are doing to pulseaudio by the pcm interface.  We could add a
universal bug for this and associate all effected applications with it.

Once they have uninstalled pulseaudio the means to get them to debug is
completely gone.  Its the need to uninstall I wish to avoid as much as able so
progress tracking down where wine and pulseaudio hate each other can be done
more successfully.

ALSA_CONFIG_PATH  Is not exactly ideal since this is the global lets change
everything.  Ideal would be a ALSA_CONFIGRC_FILE option what would basically be
alsalib go read the .asoundrc file but ALSA does not have this option.  Yes one
of the reasons why this has been such a pain in ass for so long you can not
change the user modification in ALSA by environmental var.

ALSA_CONFIG_PATH option is something global controlled on and off that could be
controlled on an off with the suspend.  So avoiding user errors with wine we
have happen.  Ok its bad enough when someone installs stuff in the wrong
WINEPREFIX because they exported it. But breaking global sound to the desktop
is not good for us.

Not exactly sending default to dmix.  You only need to be able to set default
to point to sysdefault when suspended.  Then switch it back when not.

Exit suspend with how evil I know wine can be with lost background processes a
find and destroy anything connected to the hardware to allow pulseaudio back
would also be a wise addition as well.  Its the cleaning up bit is why I have
seen this as required as part of the pa suspend and unsuspend process.  Yes
allowed to yell long and loud about applications not cleaning up when
terminated.

If wine was not a loader like ld.so this problem would not be as hard.  Its the
fact wine is a loader is what takes out doing a command line option.

Working well enough to debug with min setting changes to applications is what I
am after.  This way you can just switch between the two modes knowing you did
not change a thing or screw a thing up.

The biggest problem from wine is the process forking and knowing when to end
the changed settings.  The Pulseaudio stop suspend process is the point you
know for sure non alsa settings used for pulseaudio can be ended.  This is why
wine setting its self runs into problems.  The setting has to align with
Pulseaudio state not aligned causes a stack of problems.  Pulseaudio entering
suspend is also when you know you should change settings.  So to us it always
appears as something that should be part of Pulseaudio since its the bit that
knows when it entering suspend and leaving suspend. 

Yes even if it a special option like pasuspender --enable-default  Then at end
of suspend remove default change.  I know its been simpler for pulseaudio to
push work around default back onto applications.  Problem here wine is not an
application.  Wine is an application loader.  Loaders have a very hard time
working out when settings should be terminated.

Wine can be connected to binfmt_misc on some systems I missed mentioning this
so when in binfmt_misc altering commandline for suspend or not is impossible. 
Same headache applies to java and mono and other things that can be placed in
binfmt_misc.

Yes so some have been thinking wine is asking for some special alteration that
other applications don't need.  This is a case of not seeing wine as the
correct class of thing.  Other application loader will gain from pasuspender
doing the right thing with default or being able to be told todo the right
thing with default.

The fun of being a different class and people the other end not seeing it.

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