[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