ALSA: usb-audio: guessed channel positions on a device that names its channels

ALSA: usb-audio: guessed channel positions on a device that names its channels

[Mikhail Gavrilov]

Hello,
I ran into this setting up a Topping M62 on Linux. It is a USB
interface with ten playback channels and sixteen capture channels --
five stereo pairs out, a set of inputs and loopback returns in. Nothing
about it is a home cinema. But alsamixer labels its playback controls
M62 Front, Rear, Center, Woofer and Side, its capture controls Mic
Front, Rear, Center, Woofer and Side, and a player that lists ALSA
devices directly offers "5.1 Surround output to Front, Center, Rear and
Subwoofer speakers" for it. Choosing one of those gives silence or the
wrong pair, and nothing explains why.

The layout is not in the descriptors. Every AudioStreaming interface on
this device declares bmChannelConfig 0x00000000. It comes from
convert_chmap() in sound/usb/stream.c:

} else {
/* If we're missing wChannelConfig, then guess something
   to make sure the channel map is not skipped entirely */
if (channels == 1)
chmap->map[c++] = SNDRV_CHMAP_MONO;
else
for (; c < channels && *maps; maps++)
chmap->map[c++] = *maps;
}

for (; c < channels; c++)
chmap->map[c] = SNDRV_CHMAP_UNKNOWN;

The standard position list is walked positionally, so channel 3 becomes
FC, channel 4 LFE and so on, while the honest answer the next lines
already use for the tail -- SNDRV_CHMAP_UNKNOWN -- never reaches the
head.

What makes this more than an unlucky guess is that the device does say
what its channels are, in the field beside the one we read:

bNrChannels            10
bmChannelConfig    0x00000000
iChannelNames          11 Playback 1

bNrChannels            16
bmChannelConfig    0x00000000
iChannelNames          21 Analogue 1

iChannelNames indexes the name of the first channel and the rest follow
in order. Reading those string descriptors from the same Linux machine
gives:

11  Playback 1        21  Analogue 1      29  Loopback 1
12  Playback 2        22  Analogue 2      30  Loopback 2
13  Playback 3        23  AUX 1           31  Loopback 3
14  Playback 4        24  AUX 2           32  Loopback 4
15  Playback 5        25  BT 1            33  Loopback 5
16  Playback 6        26  BT 2            34  Loopback 6
17  Playback 7        27  Mobile 1        35  Loopback 7
18  Playback 8        28  Mobile 2        36  Loopback 8
19  Playback 9
20  Playback 10

That is the hardware, exactly: two microphone inputs, a stereo AUX, a
Bluetooth return, a phone return and eight loopback returns. In
sound/usb the field appears only in validate.c, counted towards a
descriptor's expected length and never read.

Two questions, then, and I would rather ask than send a patch that
guesses at the answer.

Should the positional guess stop where the position list stops meaning
anything? For two channels it is almost always right and clearly
useful. For ten or sixteen it is not uncertain but wrong, and UNKNOWN
is both honest and already available.

And is there interest in surfacing iChannelNames at all? The chmap API
is positional and has no room for free text, so this is not a matter of
filling in a map -- it would need somewhere new to live, and I do not
want to invent that unilaterally. But devices do provide these names,
and on an interface with ten identical-looking channels they are the
only thing that tells a user which is which.

Happy to write either patch if a direction is agreeable.

-- 
Thanks,
Mikhail Gavrilov.

Re: ALSA: usb-audio: guessed channel positions on a device that names its channels

[Takashi Iwai]

On Mon, 24 Aug 2026 00:55:21 +0200,
Mikhail Gavrilov wrote:
> 
> Hello,
> I ran into this setting up a Topping M62 on Linux. It is a USB
> interface with ten playback channels and sixteen capture channels --
> five stereo pairs out, a set of inputs and loopback returns in. Nothing
> about it is a home cinema. But alsamixer labels its playback controls
> M62 Front, Rear, Center, Woofer and Side, its capture controls Mic
> Front, Rear, Center, Woofer and Side, and a player that lists ALSA
> devices directly offers "5.1 Surround output to Front, Center, Rear and
> Subwoofer speakers" for it. Choosing one of those gives silence or the
> wrong pair, and nothing explains why.
> 
> The layout is not in the descriptors. Every AudioStreaming interface on
> this device declares bmChannelConfig 0x00000000. It comes from
> convert_chmap() in sound/usb/stream.c:
> 
> } else {
> /* If we're missing wChannelConfig, then guess something
>    to make sure the channel map is not skipped entirely */
> if (channels == 1)
> chmap->map[c++] = SNDRV_CHMAP_MONO;
> else
> for (; c < channels && *maps; maps++)
> chmap->map[c++] = *maps;
> }
> 
> for (; c < channels; c++)
> chmap->map[c] = SNDRV_CHMAP_UNKNOWN;
> 
> The standard position list is walked positionally, so channel 3 becomes
> FC, channel 4 LFE and so on, while the honest answer the next lines
> already use for the tail -- SNDRV_CHMAP_UNKNOWN -- never reaches the
> head.
> 
> What makes this more than an unlucky guess is that the device does say
> what its channels are, in the field beside the one we read:
> 
> bNrChannels            10
> bmChannelConfig    0x00000000
> iChannelNames          11 Playback 1
> 
> bNrChannels            16
> bmChannelConfig    0x00000000
> iChannelNames          21 Analogue 1
> 
> iChannelNames indexes the name of the first channel and the rest follow
> in order. Reading those string descriptors from the same Linux machine
> gives:
> 
> 11  Playback 1        21  Analogue 1      29  Loopback 1
> 12  Playback 2        22  Analogue 2      30  Loopback 2
> 13  Playback 3        23  AUX 1           31  Loopback 3
> 14  Playback 4        24  AUX 2           32  Loopback 4
> 15  Playback 5        25  BT 1            33  Loopback 5
> 16  Playback 6        26  BT 2            34  Loopback 6
> 17  Playback 7        27  Mobile 1        35  Loopback 7
> 18  Playback 8        28  Mobile 2        36  Loopback 8
> 19  Playback 9
> 20  Playback 10
> 
> That is the hardware, exactly: two microphone inputs, a stereo AUX, a
> Bluetooth return, a phone return and eight loopback returns. In
> sound/usb the field appears only in validate.c, counted towards a
> descriptor's expected length and never read.
> 
> Two questions, then, and I would rather ask than send a patch that
> guesses at the answer.
> 
> Should the positional guess stop where the position list stops meaning
> anything? For two channels it is almost always right and clearly
> useful. For ten or sixteen it is not uncertain but wrong, and UNKNOWN
> is both honest and already available.
> 
> And is there interest in surfacing iChannelNames at all? The chmap API
> is positional and has no room for free text, so this is not a matter of
> filling in a map -- it would need somewhere new to live, and I do not
> want to invent that unilaterally. But devices do provide these names,
> and on an interface with ten identical-looking channels they are the
> only thing that tells a user which is which.
> 
> Happy to write either patch if a direction is agreeable.

I'd say yes for both.  It's beyond the standard definition, so we'd
just need to do the best.


thanks,

Takashi