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

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