generating alsa configs for bluealsa

[borine]

I've put up an experimental commit in a branch on my bluez-alsa fork here: https://github.com/borine/bluez-alsa/tree/dynamic

This edits the ALSA config in-memory when devices connect/disconnect such that name hints are added and removed as required.
To use it you need to have ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:/usr/share/bluealsa/alsa-dynamic.conf exported into the environment of the alsa application (eg aplay etc).

Ive tested it with aplay where I get good results, and with kodi where it is less successful. kodi reads the namehints on startup but after that only when a sound card is plugged/unplugged (I'm guessing via udev event) , so the dynamic aspect is completely missed.

[graham8]

Nice! Yes Kodi listens to udev for soundcards. We have a patch to have it listen for BT devices connecting but udev doesn't know what sort of bluetooth device it is. We were thinking of adding a dbus listener but I'll have a look at your patch and see if we can meet in the middle.

[borine]

We were thinking of adding a dbus listener

That will certainly work with my approach. There is also a simpler option of just calling snd_device_name_hint() every time the audio device selection dialog is opened. Its not so expensive and guarantees that all device types are checked, not just soundcards and bluetooth (assuming other theoretical software devices become available)

[graham8]

Ok, thanks. I guess this namehints tree (which I will need to research) is something that can only be manipulated with calls to the alsalib API, not through config files, then.

[borine]

No, it is actually intended for users to populate. By default it does not exist at all. The documentation is here: https://github.com/alsa-project/alsa-lib/blob/23a191a82c693456e61431ab699cddc1e5782a26/src/control/namehint.c#L556
The doxygen tags in that file appear to be broken, so it does not appear in the alsa-project C API online documentation. And there is also an error in the examples: they omit the keyword DESC so thay actually don't work!

A namehint node should be of the form:
id "bluealsa:xx:xx:xx:xx:xx:xx,PROFILE=a2dp|DESCThis is the text that is shown to the user|IOIDOutput"

The id can be any unique key - it is not shown to the user, but can be used to progamatically search for it if you later need to delete it. The |IOID section is optional and determines whether the device is listed as Playback (Output) or Capture (Input). If omitted, the device is treated as both input and output.

The purpose of a namehint entry is to be used in combination with a parameterized device (such as bluealsa). It allows the user to have a namehint for a specific combination of arguments. So if you need to define new pcms for some other reason than just creating a hint, then the namehint tree is probably not right for you.

I've thought about your approach, and here's what I suggest (FWIW):

snd_pcm_open() updates the global config tree then searches for the requested pcm node in that tree. The function used to do the update is snd_config_update_r() which checks timestamps on alsa's global config files and only re-reads the config if one of those files has changed since the last read. It does not check timestamps on local config files so changing them does not get the in-memory copy refreshed. The "global" files are the ones listed in ALSA_CONFIG_PATH. If that variable is empty or does not exist it uses the single file /usr/share/alsa/alsa.conf. So the file you put your bluealsa pcm definitions in must be a "global" file, not a "local" one. So don't use ~/.asoundrc or /etc/asound.conf or anything in /etc/alsa/conf.d. Instead, use a writeable location that is not otherwise used by alsa. I recommend /var/lib/OSMC/alsa.conf, or whatever is appropriate in the OSMC filesystem. then add that file to the global config with ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:/var/lib/OSMC/alsa.conf. Now the config will be re-loaded every time you change your bluealsa pcm definitions.

Another potential issue for you is that presumably you have a daemon that writes the pcm definitiions in response to a d-bus event. Then you also want kodi to read the definition in response to the same event - that is a classic race condition. Maybe on Vero your daemon wins, but on RPi kodi wins,

[graham8]

Very helpful, thanks! the world is divided into those who don't understand ALSA and those who do but don't have the time to document it. You are a rare exception!

The RPi issue could well be a race problem but I don't think that's the complete answer.

[borine]

Incidentally, I've just found a "clunky" way to get kodi to regenerate its Audio device list when a bluealsa device connects/disconnects: force a udev event with modprobe snd-dummy; modprobe -r snd-dummy (actually thats 2 events, but it gets the job done).

So write or delete a namehint entry for the bluealsa device, then load/unload the dummy card to let kodi know the config has changed. No need for plugins or environment variables or kodi patches, all doable within your bluealsa monitoring daemon.

[graham8]

Interesting, but we don't have a snd-dummy module in our build. We have already patched the udev listener to listen for bluetooth device connections.