[PATCH 3/9] conf: Read a host-specific asoundrc

Takashi Iwai tiwai at suse.de
Tue Jun 23 13:45:34 CEST 2020


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 at xwax.org>
> > > > 
> > > > 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


More information about the Alsa-devel mailing list