| Message ID | 20200622131515.23385-3-mark@xwax.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/9] control: Fix typos in the namehint example | expand |
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@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. thanks, Takashi > --- > src/conf/alsa.conf | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/src/conf/alsa.conf b/src/conf/alsa.conf > index 18427ec6..4dae0e9c 100644 > --- a/src/conf/alsa.conf > +++ b/src/conf/alsa.conf > @@ -24,6 +24,17 @@ > "/alsa/asoundrc" > ] > } > + { > + @func concat > + strings [ > + "~/.asoundrc-" > + { > + @func getenv > + vars [ HOSTNAME ] > + default "localhost" > + } > + ] > + } > ] > errors false > } > -- > 2.17.5 >
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@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. Though I do have vague recollection of trying this some years ago. I think perhaps I ad issues using it to read other config files. I will re-visit when I have time. FYI To solve my development work, I have: ~/.asoundrc -- my personal settings ~/.asoundrc-xxx -- host specific settings and I must read both, in that order.
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@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. thanks, Takashi > Though I do have vague recollection of trying this some years ago. I think > perhaps I ad issues using it to read other config files. I will re-visit > when I have time. > > FYI To solve my development work, I have: > > ~/.asoundrc -- my personal settings > ~/.asoundrc-xxx -- host specific settings > > and I must read both, in that order. > > -- > Mark >
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@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. 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.
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@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
diff --git a/src/conf/alsa.conf b/src/conf/alsa.conf index 18427ec6..4dae0e9c 100644 --- a/src/conf/alsa.conf +++ b/src/conf/alsa.conf @@ -24,6 +24,17 @@ "/alsa/asoundrc" ] } + { + @func concat + strings [ + "~/.asoundrc-" + { + @func getenv + vars [ HOSTNAME ] + default "localhost" + } + ] + } ] errors false }
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@xwax.org> --- src/conf/alsa.conf | 11 +++++++++++ 1 file changed, 11 insertions(+)