Re: channel names

[Adrian Knoth <adi@drcomp.erfurt.thur.de>]

On 02/08/2013 07:52 AM, Takashi Iwai wrote:

>> Am I missing something or doesn't ALSA support channel names?
>>
>> When dealing with multichannel interfaces, it's pretty inconvenient to
>> remember whether channel 193 is on MADI 3, AES-EBU or phones.
>>
>> We can address this on the jackd level, however, since OSX allows audio
>> drivers to name their channels, I wonder how to do the same with ALSA?
> It's possible to give some information via the new channel map API,

I'm afraid the channel map may not work for pro-audio interfaces. While
consumer devices will surely benefit from a label like

   SNDRV_CHMAP_RRC,        /* rear right center */

professional-grade cards simply don't have such channel names.

Instead, "our" channels have names like

   ADAT 7
   Line 12
   Bus 14L

or however else the vendor decided to call (and physically label) them.

That said, we'd probably end up with plenty of new definitions, and we'd
still need the reverse translation from the enum to a string in
userspace.

(NB: Things are so much easier with FFADO, where devices provide a
name vector of strings that's then exposed to jackd.)

How about struct snd_pcm_channel_info?

struct snd_pcm_channel_info {
        unsigned int channel;
        __kernel_off_t offset;          /* mmap offset */
        unsigned int first;             /* offset to first sample in bits */
        unsigned int step;              /* samples distance in bits */
};


This looks like the natural place for a new struct member

        char name[64];


Maybe there are better places for such an extension, I'm not an ALSA-API
expert.


Do we already agree that verbose strings are useful? At least the Win
and OSX audio guys think so. ;)


Cheers