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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Tanu Kaskinen <tanuk at iki.fi> 2012-06-04 23:39:25 PDT ---
(In reply to comment #10)
> Tanu Kaskinen
> "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."
> 
> This is two problems.
> 1) Is dealing with new people.    Wine gets a lot of people new to Linux
> command line.  So incompetent is not uncommon attempting debugging remotely.
> 
> So they do something nasty and evil like "export WINESETTING=<setting>; wine
> <program>" instead of "WINESETTING=<setting> wine <program>" the second one is
> temporary first one is stuck in environment.
> 
> Yes the first results in a value living on after pasuspender would have been
> ended to reallow pulseaudio.  So cause us to be yelled at for breaking their
> pulseaudio.  So if we were setting a environmental var we need to be sure it
> will be cleaned up when suspend ends.  So any extra environment var is a extra
> way to drive wine support people up wall if they have to instruct users todo
> it.

Users will copy-paste what you tell them to copy-paste. If you don't mention
the "export" command, they won't even know that such command exists.

> 2) windows applications.  They look up for information on hardware from the
> registry yes wine has to show a device id to applications.
> 
> There are two different entries in registry one for voice out and one for
> general audio out.  Same with input in.  This is required for windows
> application compatibility.  So changing on fly would look to application that
> you changed sound card.  This can upset some applications.

Changing on the fly? What? You don't change the environment variable while the
application is running.

> ALSA_CONFIG_PATH  Is not exactly ideal since this is the global lets change
> everything.  Ideal would be a ALSA_CONFIGRC_FILE option what would basically be
> alsalib go read the .asoundrc file but ALSA does not have this option.  Yes one
> of the reasons why this has been such a pain in ass for so long you can not
> change the user modification in ALSA by environmental var.
> 
> ALSA_CONFIG_PATH option is something global controlled on and off that could be
> controlled on an off with the suspend.  So avoiding user errors with wine we
> have happen.  Ok its bad enough when someone installs stuff in the wrong
> WINEPREFIX because they exported it. But breaking global sound to the desktop
> is not good for us.

I'm not sure if you understood what I meant. It sounds like you think that I
was suggesting that the user would set ALSA_CONFIG_PATH himself. I didn't mean
that. pasuspender would set the environment variable, and it would only affect
the process (and its children) that is started by pasuspender. The user
wouldn't even know, without reading pasuspender man page, that ALSA_CONFIG_PATH
is being set.

> Not exactly sending default to dmix.  You only need to be able to set default
> to point to sysdefault when suspended.  Then switch it back when not.

So sysdefault is better than dmix? Ok, fine.

> If wine was not a loader like ld.so this problem would not be as hard.  Its the
> fact wine is a loader is what takes out doing a command line option.
> 
> Working well enough to debug with min setting changes to applications is what I
> am after.  This way you can just switch between the two modes knowing you did
> not change a thing or screw a thing up.
> 
> The biggest problem from wine is the process forking and knowing when to end
> the changed settings.  The Pulseaudio stop suspend process is the point you
> know for sure non alsa settings used for pulseaudio can be ended.  This is why
> wine setting its self runs into problems.  The setting has to align with
> Pulseaudio state not aligned causes a stack of problems.  Pulseaudio entering
> suspend is also when you know you should change settings.  So to us it always
> appears as something that should be part of Pulseaudio since its the bit that
> knows when it entering suspend and leaving suspend. 
> 
> Yes even if it a special option like pasuspender --enable-default  Then at end
> of suspend remove default change.  I know its been simpler for pulseaudio to
> push work around default back onto applications.  Problem here wine is not an
> application.  Wine is an application loader.  Loaders have a very hard time
> working out when settings should be terminated.
> 
> Wine can be connected to binfmt_misc on some systems I missed mentioning this
> so when in binfmt_misc altering commandline for suspend or not is impossible. 
> Same headache applies to java and mono and other things that can be placed in
> binfmt_misc.

I don't think this aspect is very relevant here. When you use pasuspender,
you'll have to run it like "pasuspender -- wine program.exe" (or I guess
"pasuspender -- program.exe" works too).

If I understood correctly, you'd like to just run "pasuspender suspend" or
something like that, and the system would enter to direct alsa mode, and
"pasuspender unsuspend" would return to normal pulseaudio mode. I don't think
that's doable. I believe that there's no sane way for changing the global
settings safely, let alone changing the audio mode of already-running
applications.

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