channel names

channel names

[Adrian Knoth]

Hi!

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?


Cheers

Re: channel names

[Takashi Iwai]

At Thu, 07 Feb 2013 22:23:15 +0100,
Adrian Knoth wrote:
> 
> Hi!
> 
> 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,
but things like AES-EBU or phone aren't defined there.  We'd need new
value definitions for such.


Takashi

Re: channel names

[Florian Faber]

On 02/08/13 07:52, Takashi Iwai wrote:
> At Thu, 07 Feb 2013 22:23:15 +0100,
> Adrian Knoth wrote:
>>
>> Hi!
>>
>> 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,
> but things like AES-EBU or phone aren't defined there.  We'd need new
> value definitions for such.

There might be interfaces that change the type of connection depending
on the current configuration (clock setting, pluggable hardware modules
etc.).

In the hdsp(m) and marian drivers I added ports.in and ports.out in
/proc which contain a list with the current physical port names. It is a
quick hack, but it works fine together with a patch for jack that
imports this list.


Flo
-- 
Machines can do the work, so people have time to think.
public key B3B9226C

Re: channel names

[Adrian Knoth]

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

Re: channel names

[Clemens Ladisch]

Adrian Knoth wrote:
> 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's what the SNDRV_CHMAP_DRIVER_SPEC flag is for.

Furthermore, there isn't necessarily a 1:1 mapping between PCM channels
and physical I/Os.

> How about struct snd_pcm_channel_info?
>
> Maybe there are better places for such an extension, I'm not an ALSA-API
> expert.

That place would be the ALSA media controller API.
(I should implement it some day ...)


Regards,
Clemens

Re: 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