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