https://bugs.freedesktop.org/show_bug.cgi?id=50256
--- Comment #9 from Tanu Kaskinen <[email protected]> 2012-06-02 00:15:18 PDT --- (In reply to comment #8) > 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. Ok, I can understand that propagating the command line arguments when forking isn't very nice. An environment variable for configuring the audio backend should still be a viable option, except you say that it isn't: > 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. 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. > 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. If pulseaudio causes huge amounts of memory use while dmix doesn't, it would be interesting to know what the applications are doing. It might be possible to add some checks to pulseaudio to prevent the excessive memory use. > 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. Yes, and if it doesn't work when "default" is defined to use pulseaudio, it's a bug that needs to be fixed. It should not be just worked around by using pasuspender, but 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... > Making default always work one way or the other cannot be too hard. There are various levels of "working". Making audio "fully work" with pasuspender will probably never be achieved, and it's not the goal either. That said, I'm starting to think that it does make sense to change the "default" alsa device in pasuspender after all, or at least provide an option for it. I earlier thought that it would require messing with the user's .asoundrc file, which would be a nightmare, but then I realized that actually the alsa library supports the ALSA_CONFIG_PATH environment variable, and it overrides all other alsa configuration files. We can ship an alsa configuration file with pulseaudio that is normally not used for anything, but pasuspender can set ALSA_CONFIG_PATH to point to it. That configuration file would set default to dmix. -- 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
