PCM channel names

PCM channel names

[Philippe Bekaert]

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.

Re: PCM channel names

[Takashi Sakamoto]

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