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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #17 from Tanu Kaskinen <tanuk at iki.fi> 2012-06-07 12:07:18 PDT ---
(In reply to comment #16)
> If someone has hardware issues and they are wanting to test that out they might
> have intentionally set ALSA_CONFIG_PATH to alter how Alsa inits up.

I think the --redefine-alsa-default-pcm={yes,no} parameter should behave so
that if it's not given at all, then ALSA_CONFIG_PATH is set, unless it's
already set. Explicitly giving --redefine-alsa-default-pcm would set
ALSA_CONFIG_PATH even if it's already set. That should cover the 1% of cases
where the user actually has set ALSA_CONFIG_PATH himself.

> Now we have the idea go and override this is this wise.  Each environmental var
> should have a role.   Currently its abused  ALSA_CONFIG_PATH global hardware
> defines is in the alsa.conf files.  Temp overrides should exist as a different
> environmental option.  This would make life so many times simpler. 

It's not terribly complicated to load /usr/share/alsa/alsa.conf in the
beginning of the custom configuration file...

> The bending of ALSA_CONFIG_PATH tracks to stacks and stacks of historic stuff
> ups.   The .asoundrc was always intended for those more temporary settings. 
> Problem was we were never given a environmental var to push it around.

I'd imagine that ~/.asoundrc is not primarily for temporary changes (of course
it can be used for that too). ~/.asoundrc is useful for permanent user-specific
configuration.

> So hardware setting and temp settings are getting bashed around by one
> environmental var this does explain why it goes so badly wrong.
> 
> Wine has global defines like the base if it default registry.  This is read
> every time a prefix is created.   Then we have more localised configurations
> contained to the WINEPREFIX.
> 
> So my use of global is exactly correct.  Its more way of thinking about what
> you should and not be playing with.   Playing with wine registry master
> template location of wine registry is not the correct way to address a
> application problem.
> 
> This case we have a single application we are trying to fix yet we are moving
> the look up location to configure sound cards and hoping the one we point to
> points back to the correct one.  This spells trouble to me.

I don't see the problem. Just make sure that the base configuration is loaded
from the custom configuration file.

> If a alsa envormental var existed for pulseaudio, jackaudio and any other audio
> server or per application alterations of sound config so avoiding touching
> ALSA_CONFIG_PATH that contains information to setup hardware at times. 
> Failures would be reduced.
> 
> "ALSA_CONFIG_PATH 
>     file to use instead of ALSA_CONFIG_DIR/alsa.conf" 
> ALSA_MIXER_SIMPLE 
>     file to use instead of ALSA_CONFIG_DIR/smixer.conf 
> ALSA_MIXER_SIMPLE_MODULES 
>     path to modules .so files"
> Nothing currently provided is correct for the problem at hand.

It sounds like you are talking about some other problems than the one at hand.
Or at least to me ALSA_CONFIG_PATH seems perfectly usable for redefining
pcm.default as pcm.sysdefault.

> You say it would be hard to do a full alsa as if untouched in pasuspender. 
> Reality this is only because of lack of clear separation of roles in the
> environmental vars.
> 
> If sound server settings were not mixed with hardware configuration information
> in alsa.conf existing back to a pure alsa would be very straight forwards.
> 
> Like if a ALSA_ASOUNDRC_FILE option existed in the library or
> ALSA_SOUNDSERVER_FILE existed in the library for extra settings and sound
> servers used this.  That file would contain like all your pulseaudio setup
> stuff.  So remove then remove var and magically alsa application would init up
> like pulseaudio is not running as long as pulseaudio had disconnected from the
> audio.

This sounds like you'd want ALSA_SOUNDSERVER_FILE to be always set when using
Pulseaudio. I think that's a bad idea. Managing this kind of session-wide
environment variables is very user-unfriendly, and an additional problem is
that there is no single standard file where per-user environment variables can
reliably be stored (at least it used to be so that terminal sessions and X
sessions had completely separate initialization scripts, and even different
desktop environments used different scripts, so there was no central file to
put environment variables that should be set regardless of the session type).
Maybe I misunderstood what you were suggesting?

Also, it indeed needs "magic" to remove a session-wide environment variable.
Without magic, a relogin is needed, which is not very cool.

> Yes the reality is alsa was designed to be able to change configuration at lot.
>  But someone presumed that users would only need one configuration file so
> never made .asoundrc environmental var settable.
> 
> Wine without its WINEPREFIX environmental var would be the same problem.  For
> us this would be 100 percent unworkable and we cannot understand why audio guys
> keep on trying to place all settings in the one alsa.conf files.

You could explicitly load the master template from the prefix configurations.
That should work equally well as your current situation. I'm not arguing that
it would be a better option for you, only that it would be workable.

>  Then complain
> things get hard.  Not seeing that the problem is not having a single extra
> environmental var you need.

I have failed to understand what problem extra environment variables would
solve.

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