https://bugs.freedesktop.org/show_bug.cgi?id=50256
--- Comment #16 from [email protected] 2012-06-06 06:56:57 PDT --- Opps I moused clicked at the wrong time. ALSA_CONFIG_PATH really I would prefer to avoid touching this if we can. Historically its been the universal way to stomp on ALSA to make it do what you wish. But that does not really make it right. 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. 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. 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. 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. 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. 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. 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. Then complain things get hard. Not seeing that the problem is not having a single extra environmental var you need. Remember when ALSA started ALSA_CONFIG_PATH did not exist either it was hard coded into the library. Current ~/.asoundrc is hard coded this is the file that should contain all the users own unique configuration changes. Sound server should be in .asoundrc somehow. Most likely as a environment var telling applications where to look .asoundrc up from. This also would have allowed wine to work around the pulseaudio suspender issue. Hey read this .asoundrc file that corrects default to point somewhere sane. When something is hard coded when it should not be leaded to doing stacks of painful operations to oneself without any sane need. This is why pulseaudio has such a hard time dropping back to alsa without pulseaudio. -- 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
