https://bugs.freedesktop.org/show_bug.cgi?id=50256
--- Comment #12 from [email protected] 2012-06-05 01:49:01 PDT --- 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. This is also why export is used on a few environment vars with wine since some wine will pickup on fly. pasuspender -- program.exe can be true if binfmt-misc is set. Yes thinking that wine is a normal program is causing problem here. Idea that you could simply just override something does not exist with wine. Wine needs to be able to have the same audio settings when pulseaudio is running and when its suspended. Otherwise you are playing with altering settings on a running system and hope it don't destroy something. Wine is lucky that the alsa lookups are loader side not service/daemon side. But configuration data is in registry because it has to be. "I believe that there's no sane way for changing the global settings safely, let alone changing the audio mode of already-running applications." This is what we have to pull off with wine to be windows compatible. Yes it would be possible to connect wine sound system to a system wide service to be notified of a audio change and have wine alter to suit without applications using wine being too upset most of the time. But no such global service to notify applications of alsa setting changes exist. So yes its possible with a little work on the wine alsa driver to keep on outputting sound while pulseaudio is suspended and to returned to pulseaudio when suspend ends. That is of course if there is some from of framework to inform wine what is going on. Wine has emulated windows means to change sound card on fly fairly well not as complete as it could be. So when it comes to wine changing audio mode of a running application would fall into camp of annoyance. Do able by what wine has had to implement but nothing exists globally to inform wine of changes. Yes this is a weakness of alsa. Alsa retakes it configuration every time it runs. But no one include a service to inform applications of change settings now. It would be surprising how powerful Alsa could come just with something to manage its settings and to allow setting changes on fly. Tanu Kaskinen "So sysdefault is better than dmix? Ok, fine." sysdefault has any extra setting the hardware needs to operate. Where plan dmix might try sending the wrong speed or width audio to the device. So yes better. -- 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
