[alsa-devel] channel names

[Takashi Iwai]

At Fri, 08 Feb 2013 14:39:16 +0100,
Adrian Knoth wrote:
> 
> 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.

For such special purposes, we thought to allow the driver to use its
own definition (SNDRV_CHMAP_DRIVER_SPEC bit mask), but yes, it's still
limited to an integer.

> 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];

Extending snd_pcm_channel_info would break ABI, so it'll be anyway a
different thing.  That is, we can start from scratch.

> 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. ;)

The verbose string would be fine.  The automatic conversion from the
existing chmap can be easily done, too.  The only question is a sane
implementation :)


Takashi