Hi, I'm a maintainer of ALSA firewire stack, which supports drivers for audio and music units in IEEE 1394 bus, including some recording equipments such as RME Fireface series. On Wed, Aug 18, 2021 at 05:16:24PM +0200, Philippe Bekaert wrote: > Same context as my previous mail … > > The RME HDSPe cards have a large number of input and outputs for which the > standard ALSA channels names and mappings make little sense. > > Names depend on the card, e.g. Analog.L, Analog.R, AES.1/1 … AES.1/8, > ADAT.1 … ADAT.8 etc… > > Right now, the hdspm driver provides a ad-hoc virtual file in > /proc/asound/card<n> containing these names. > > Isn’t there a more generic interface to communicate PCM channel names > from driver to user space > > Same questions as before: > > Has anyone been facing similar issues? How have you been solving it? Is > there any “common practice” or “habits” in this community concerning > this topic? Would it make sense to define a kind of generic interface > for PCM naming? Then, has anyone an idea or preference how it should > look like? > > Again looking forward to your feedback. > > Best regards and thanks in advance, > > Philippe. I have the same issues, see: Enhancement request: Add "pretty" port names · Issue #32 https://github.com/takaswie/snd-firewire-improve/issues/32 Actually, in regard of kernel/userspace interaction, we have 'channel map' structure for Type-Length-Value (TLV) API in ALSA control character device (see 'include/uapi/sound/asound.h' and 'include/uapi/sound/tlv.h'). The structure consists of array with channel position and its role defined by SNDRV_CHMAP_XXX macros. The macros seem to be designed for standard surround channels such as 2.1 ch, 6 ch, 7.1 ch and so on. Some userspace applications handles the data of structure for construction of surround channels. However, in recording equipments, the design might not be suitable since audio data for analog and digital inputs and outputs are transferred in the same PCM substream. In the case, we can not find standard surround channels on audio data frame in the substream. Furthermore, as long as userspace applications expects standard surround channels, it's not better to integrate the channel map structure simply for our purpose. I think it better to design another way as comprehensive solution, but I have never found any good way. The most realistic way is to deliver string literal such as 'analog-input-2' and 'adat-output-5', however it can confuse userspace applications unless any standardization or conventions since any string expressions can be delivered. Furthermore, it includes inefficiencies in kernel memory consumption. Regards Takashi Sakamoto
