From: GitHub pull_request - edited <github@alsa-project.org>
To: alsa-devel@alsa-project.org
Subject: ucm2: USB-Audio: add Topping M62 configuration
Date: Tue, 11 Aug 2026 14:29:58 +0200 (CEST) [thread overview]
Message-ID: <18cac01437004100-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <alsa-project/alsa-ucm-conf/pr/826@alsa-project.org>
alsa-project/alsa-ucm-conf pull request #826 was edited from NTMan:
ucm2: USB-Audio: add Topping M62 configuration
The M62 exposes a single ten channel playback PCM and a single sixteen
channel capture PCM. The ten playback channels are not a surround
layout: they are five independent stereo buses that the card's own
mixer sums into its outputs, named Playback 1/2 to Playback 9/10 in the
manual.
The descriptor declares no channel positions at all -- bmChannelConfig
is 0x00000000 on both the ten channel and the sixteen channel terminal
-- and the card exposes no ALSA channel map either, neither a kcontrol
nor a /proc entry. Without a profile the host therefore invents one:
PipeWire fills ten unnamed channels with its default surround layout,
so the desktop believes in a centre, an LFE and a rear that the
hardware does not have, or else hands out AUX0..AUX9. Both readings
break more than cosmetics: the balance control and the speaker test
have nothing to work with, and any per device equalisation carries ten
channel keys where two are meant.
Each bus is therefore published as its own stereo device, split out of
the one PCM. The five are not marked conflicting: they may play at
once, which is the point of having five.
What the card does declare is channel NAMES. iChannelNames points at
"Playback 1" on the playback terminal and at "Analogue 1" on the
capture terminal, each the first of a consecutive run of string
descriptors, and the run reads Analogue 1, Analogue 2, AUX 1, AUX 2,
BT 1, BT 2, Mobile 1, Mobile 2 and Loopback 1 to 8. macOS displays
exactly those because Core Audio follows that field. Every name in
this profile comes from there. Linux surfaces none
of it: ALSA carries channel positions through chmap and has no notion
of a channel name, so the host sees an anonymous sixteen and this
profile is where the names can live. The order was confirmed by
measurement as well, one column at a time -- feeding the microphone
input lights column 0, and a headphone to AUX loop lights columns 2
and 3.
The inputs are therefore published under the names the card's own
panel and control application use: IN 1, IN 2, AUX, BT and OTG IN. The
two microphone channels are named after the card's mic channels and not
after jacks, because IN 1 is switched on the card between its own
6.3 mm jack, the 3.5 mm jack and the headset jack; that switch lives in
the card's own panel and is not visible to the driver, so a jack name
would be a claim the configuration cannot back.
IN 1 and IN 2 are also offered together as IN 1 + 2. A balanced stereo
source -- a synthesiser, a mixer's main output -- arrives on both
microphone channels at once, and offering it only as two mono devices
makes the desktop pick one half of it. It conflicts with the halves
rather than coexisting with them, since the same two columns cannot be
two devices at the same time.
Bluetooth and Mobile are declared although they carry digital silence
on the unit tested here. With Bluetooth and OTG audible in the
headphones, the card's own control panel metering both, and the
loopbacks pointed at those sources, a sixteen column recording found
signal on columns 2 and 3 only, identically under PipeWire and under
Core Audio. The vendor reports the same channels recording normally on
Windows with the same firmware and the same operating mode, so the
behaviour is not universal and the enquiry is open; a unit that fills
them should present them by name rather than as an unlabelled column.
The eight loopback returns are left undeclared until one of them is
seen to carry a sample. Eight always silent entries in a sound panel
would be eight inputs that record nothing.
The card keeps all ten playback channels in one mixer element and all
sixteen capture columns in another, so the per bus and per input
volumes come from a control remap by channel index, in the same shape
the Behringer UMC204HD profile uses.
The card has three operating modes, switched from its own panel, and
all three keep the same USB id. Mobile Mode is a plain stereo device
with an honest FL FR channel map on both directions and needs no
profile; applying this one to it would ask a two channel PCM for ten.
The mode is encoded in the high byte of bcdDevice, 01xx Mobile, 02xx
Live Streaming, 03xx Pro Audio, so the profile is selected only for the
latter two. Live Streaming and Pro Audio have identical channel layouts
and differ only in the rates they offer, 44.1 and 48 kHz against those
plus 88.2 and 96 kHz.
Tested on Fedora with alsa-lib 1.2.16 and PipeWire in all three modes:
in Live Streaming and Pro Audio the five sinks and the named sources
appear as expected, playback lands on the intended pair, each remapped
element moves only its own channels, and a sixteen column recording
confirms the input columns; in Mobile Mode the card is left to the
generic configuration.
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Attached alsa-info from all three modes. The `bcdDevice` value is what the profile keys on:
| Mode | bcdDevice | Playback | Capture | Rates (kHz) | Profile |
| --- | --- | --- | --- | --- | --- |
| [alsa-info-MobileMode.txt](https://github.com/user-attachments/files/30801211/alsa-info-MobileMode.txt) | 0145 | 2ch, FL FR | 2ch, FL FR | 44.1, 48 | not applied |
| [alsa-info-LiveStreamingMode.txt](https://github.com/user-attachments/files/30801208/alsa-info-LiveStreamingMode.txt)| 0248 | 10ch | 16ch | 44.1, 48 | applied |
| [alsa-info-ProAudioMode.txt](https://github.com/user-attachments/files/30801204/alsa-info-ProAudioMode.txt) | 0327 | 10ch | 16ch | 44.1, 48, 88.2, 96 | applied |
In the two ten channel modes the descriptor declares the channel map `FL FR FC LFE RL RR FLC FRC RC SL`, which the hardware does not have: those are five stereo buses. Mobile Mode declares `FL FR` on both directions and is left to the generic configuration.
Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/826
Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/826.patch
Repository URL: https://github.com/alsa-project/alsa-ucm-conf
next prev parent reply other threads:[~2026-08-11 12:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alsa-project/alsa-ucm-conf/pr/826@alsa-project.org>
2026-08-06 19:02 ` ucm2: USB-Audio: add Topping M62 configuration GitHub pull_request - opened
2026-08-06 19:16 ` GitHub pull_request - edited
2026-08-06 19:22 ` GitHub pull_request - edited
2026-08-06 19:22 ` GitHub pull_request - edited
2026-08-07 8:57 ` GitHub pull_request - edited
2026-08-07 9:00 ` GitHub pull_request - edited
2026-08-11 12:29 ` GitHub pull_request - edited [this message]
2026-08-11 15:48 ` GitHub pull_request - edited
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18cac01437004100-webhooks-bot@alsa-project.org \
--to=github@alsa-project.org \
--cc=alsa-devel@alsa-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.