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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #14 from Tanu Kaskinen <tanuk at iki.fi> 2012-06-05 23:21:37 PDT ---
(In reply to comment #12)
> Tanu Kaskinen
> "Changing on the fly? What? You don't change the environment variable while the
> application is running."
> 
> Ok you don't know wine.  We change settings from environment variables while
> sections of wine are still running.  So yes we do have on fly changes in
> settings.
> 
> Reality wineserver can be still running in background.  So yes with wine
> changing a environment var does trigger at times change on fly.  There is one
> wineserver instance per wine prefix.  So if user is running more than one
> application from that prefix like one that will work in pa that suspends it
> output.  Then one is run pasuspender wine application.  Welcome to mid air
> collision.
> 
> Registry in the prefix is accessed by wineserver.  All registry access in a
> prefix go threw the wineserver owning to that prefix.  This can remain running
> after application terminates.
> 
> Yes wine is not your normal application.  It has services.  Those services have
> to be synced with what is going on.  This is why wine change audio settings or
> any other setting on fly becomes a major problem at times particularly if they
> are not going to be compatible.  While PA is suspended wine applications could
> be referring to the wine registry of application running under PA or worse
> applications running under PA pulling settings from registry that have been
> altered to support suspended state.

Ok, so is the model that the first "wine" command invocation with a given
prefix will start also wineserver, and the wineserver process will be running
as long as there are wine processes using that prefix? And the audio backend
configuration affects the shared registry, because it's useful to see the
backend configuration from the windows application screenshots.

Given that setup, I now understand why the wine program indeed shouldn't take
the audio backend configuration from an environment variable. Wineserver could
still use the environment variable, but that complicates the instructions that
you would need to give to the user when running pasuspender:

First, close all wine applications ("killall wine").
Then, run "WINE_AUDIO=alsa{device=sysdefault} pasuspender -- wine program.exe".

Closing all wine applications first should ensure that the pasuspender command
will launch a fresh wineserver too, so the environment variable will have
effect. One side effect of this would be that "wine" should now query the audio
backend setting from "wineserver". (Or maybe it already does that anyway?)

If you think that would be useful, you could also write a graphical launcher
program for debugging, which would remove some of the complexity for the user.
The program could set the audio backend environment variable, kill all existing
wine processes (maybe with a "are you sure" dialog), and run the selected
application under pasuspender.

That said, I think adding the ALSA_CONFIG_PATH feature to pasuspender would
work better, because with that solution you don't have the problem that the
setting needs to be shared between wine processes. I didn't quite understand
what the problem with ALSA_CONFIG_PATH was that you tried to describe. You
talked something about it being "global", but I didn't understand what you
meant. Could you elaborate?

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