https://bugs.freedesktop.org/show_bug.cgi?id=50256
--- Comment #14 from Tanu Kaskinen <[email protected]> 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. _______________________________________________ pulseaudio-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
