On Tue, 23 Jun 2020 13:42:12 +0200, Mark Hills wrote: > > On Tue, 23 Jun 2020, Takashi Iwai wrote: > > > On Tue, 23 Jun 2020 13:18:49 +0200, > > Mark Hills wrote: > > > > > > On Tue, 23 Jun 2020, Takashi Iwai wrote: > > > > > > > On Mon, 22 Jun 2020 15:15:09 +0200, > > > > Mark Hills wrote: > > > > > > > > > > On systems with a network mounted home directory this is thoroughly > > > > > useful to allow for a core set of asoundrc settings, but with different > > > > > settings on different hosts. > > > > > > > > > > It's not possibly to implement this in our own asoundrc or local > > > > > customisation, as it's too late. The installation file must be modified. > > > > > > > > > > This is similar to ~/.Xdefaults-* on some systems. > > > > > > > > > > Signed-off-by: Mark Hills <mark@xxxxxxxx> > > > > > > > > This kind of change popping up sometimes in the past, too, and I have > > > > a mixed feeling whether to take such a change globally or not. > > > > > > > > In one side, it can work, but OTOH, if you can deal with that detail, > > > > you're certainly able to set up the environment variable easily, too. > > > > > > I'm happy for a concern to be raised. > > > > > > Can you clarify, which environment variable? > > > > > > I wasn't aware it was possible to override asoundrc with an environment > > > variable, until I looked up just now and found ALSA_CONFIG_PATH in the > > > code. > > > > Hrm, you're right, I thought we had a simple override, but it doesn't > > look so. > > > > OK, then it makes sense to take your patch. Or rather better to allow > > an own environment variable (e.g. $ASOUNDRC) instead? It's more > > flexible. > > Why not let me experiment, I'll check ALSA_CONFIG_PATH, and then see what > patch I can come up with, at least for my own use case. Sure, I'm looking forward seeing a good outcome :) > Something like $ASOUNDRC will depend on whether we want it to augment, or > fully replace the configuration. > > I did do some experiments some time ago with fully replacing ALSA > configuration; I find the defaults (eg. "Surround speakers" etc.) to be > not a good match for my setup. I found it quite difficult to reason about > the variable-driven design of the default asoundrc files and for me it > seemed to cause more problems that it was solving. But then I think I > discovered I could hack it with 'namehint' and moved on. > > But in general something which allows policy to be passed to shell profile > scripts is often not a bad thing. Yes, it makes one's life sometimes easier... Takashi
