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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Tanu Kaskinen <tanuk at iki.fi> 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.