alsa add-on configs location

[borine]

It seems that the intent of the alsa project when changing the addon config directory to the $confdir (/etc/alsa/conf.d) back in alsa-lib release 1.1.7 was that packages should still actually install to the $datadir directory (/usr/share/alsa/alsa.conf.d), but then the local admin could enable/disable indlividual configs by adding/removing symlinks in the $confdir directory. However, I have found no formal statement to that effect, its just the way it appears to be.

So perhaps bluez-alsa should consider adopting the same approach? That would then require a decision on whether the bluez-alsa build should create the required symlink, or just document that it is required as a post-install step.

I think it might be useful to invite opinions on this (especially from distribution package maintainers). The current method appears to be working fine (at least no issues have been raised on this subject since bluez-alsa switched to $confdir for default), so there is no immediate reason to change anything. This is just a heads-up for a potential issue for packagers that may need to be addressed in the future.

[graham8]

As it happens, that was going through my mind this week. At OSMC we haven't caught up with the 'use most recently connected device as default' functionality and are generating config nodes for each paired device in .asoundrc. We do have 20-bluealsa.conf in $datadir from way back but I'd just discovered it wasn't doing anything. On our distro, /etc/alsa/conf.d has only appeared since we moved from kernel 3.14 to 4.9. I'm not sure where/how it's generated but I would suggest bluez-alsa uses the same approach, for consistency.

What we're working on is a way to automatically generate alsa config nodes when a device is paired. My idea is to put a conf file for each paired device in, say, /etc/alsa/bluealsa/. I have that working off the python we use for pairing and connecting devices but it's still WIP.

[borine]

way to automatically generate alsa config nodes

I have been quietly working on a way to get ALSA config entries dynamically created/removed when devices connect/disconnect using ALSA's @hook configuration function. I then get results such as:

$ aplay -L
bluealsa:DEV=11:22:33:44:55:66,PROFILE=sco,SRV=org.bluealsa
    Libratone Zipp Mini, HFP (CVSD)
    Bluetooth Audio Output
bluealsa:DEV=11:22:33:44:55:66,PROFILE=a2dp,SRV=org.bluealsa
    Libratone Zipp Mini, A2DP (aptX)
    Bluetooth Audio Output

$ arecord -L
bluealsa:DEV=11:22:33:44:55:66,PROFILE=sco,SRV=org.bluealsa
    zipp, HFP (CVSD)
    Bluetooth Audio Input

It requires the environment variable ALSA_CONFIG_PATH to be set as AFAICT that is the only way to get global hooks to be called without editing the core /usr/share/alsa/alsa.conf file, and also many applications only read the namehints once on startup so do not pick up the changes anyway, so it is not as generally useful as I had hoped. If that would be of any interest I can prepare a PR

[graham8]

I salute you if you can get your head round how @hooks works. I would really like to keep a load of *.conf files in one directory and have alsa read them like it does with /etc/alsa/conf.d. I can't seem to get func load to work though outside of alsa.conf. I opened a question on StackOverflow but no takers yet. I would be interested to see your solution if only to see how ALSA_CONFIG_PATH works.

We have the advantage of catering for a single user application (Kodi) although users can install others. Kodi knows about the pcm name and name hints but doesn't talk bluetooth natively. We add a few characters from the BT address to the name so it can distinguish between devices with the same names.

[borine]

I'll start a new discussion about @hooks and namehints as this is getting off-topic now. Possibly later today.
see #471

[paul-1]

For piCorePlayer, I'm generating nodes dynamically as well in .asoundrc But I'm creating more than the device. I'm also creating nodes for alsaequal. The whole alsa config thing is a bit puzzling, the documentation is sure lacking.