Quirks for MacroSilicon MS2100/MS2106
John Veness
john-linux at pelago.org.uk
Wed Jun 22 22:23:50 CEST 2022
Hello,
This is my first ever kernel work, so I hope I am doing everything
correctly.
I have a USB analogue AV capture dongle with a MacroSilicon MS2100E chip
inside. PID 0x534d, VID 0x0021 (534d:0021). Apparently the MS2106 uses
the same PID/VID, so hopefully acts the same, but I don't have one to check.
For audio, the MS2100E has the same problems as the MS2109 USB HDMI
capture dongle, namely claiming 96kHz mono sound when it's actually
48kHz stereo, and with left/right channel problems.
Luckily, the fix is the exact same as that for the MS2109, as first
implemented by Marcan (Hector Martin) in July 2020. Below is a patch
which is basically a copy and paste of his, with a different VID.
I have tested this patch in 5.19.0 RC2. I haven't recruited any other
testers.
Even with this patch, there is a remaining problem, which is not present
in the MS2109. The sound sample values range from 0x0000 to 0x7fff, with
silence around 0x4000, i.e. 15-bit-ish audio. This actually sounds OK to
the ear (although half as loud as it should be), but looks odd when
looking at the waveform, and makes volume meters always think the sound
is very loud.
To convert to s16le, I can bitshift one bit left, and subtract 32768.
I'm told that this isn't something that can or should be done in the
kernel, but should be in userspace. Any more advice on how to fix this
remaining quirk would be very welcome.
Nonetheless, as I say, with the following kernel patch the captured
audio certainly sounds right, so is a big improvement and makes these
dongles usable:
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 4f56e1784932..853da162fd18 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -3802,6 +3802,54 @@ YAMAHA_DEVICE(0x7010, "UB99"),
}
},
+/*
+ * MacroSilicon MS2100/MS2106 based AV capture cards
+ *
+ * These claim 96kHz 1ch in the descriptors, but are actually 48kHz 2ch.
+ * They also need QUIRK_FLAG_ALIGN_TRANSFER, which makes one wonder if
+ * they pretend to be 96kHz mono as a workaround for stereo being broken
+ * by that...
+ *
+ * They also have an issue with initial stream alignment that causes the
+ * channels to be swapped and out of phase, which is dealt with in quirks.c.
+ */
+{
+ USB_AUDIO_DEVICE(0x534d, 0x0021),
+ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+ .vendor_name = "MacroSilicon",
+ .product_name = "MS210x",
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_COMPOSITE,
+ .data = &(const struct snd_usb_audio_quirk[]) {
+ {
+ .ifnum = 2,
+ .type = QUIRK_AUDIO_STANDARD_MIXER,
+ },
+ {
+ .ifnum = 3,
+ .type = QUIRK_AUDIO_FIXED_ENDPOINT,
+ .data = &(const struct audioformat) {
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .channels = 2,
+ .iface = 3,
+ .altsetting = 1,
+ .altset_idx = 1,
+ .attributes = 0,
+ .endpoint = 0x82,
+ .ep_attr = USB_ENDPOINT_XFER_ISOC |
+ USB_ENDPOINT_SYNC_ASYNC,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ }
+ },
+ {
+ .ifnum = -1
+ }
+ }
+ }
+},
+
/*
* MacroSilicon MS2109 based HDMI capture cards
*
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index e8468f9b007d..a72874bc0936 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1478,6 +1478,7 @@ void snd_usb_set_format_quirk(struct snd_usb_substream *subs,
case USB_ID(0x041e, 0x3f19): /* E-Mu 0204 USB */
set_format_emu_quirk(subs, fmt);
break;
+ case USB_ID(0x534d, 0x0021): /* MacroSilicon MS2100/MS2106 */
case USB_ID(0x534d, 0x2109): /* MacroSilicon MS2109 */
subs->stream_offset_adj = 2;
break;
@@ -1904,6 +1905,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
QUIRK_FLAG_IGNORE_CTL_ERROR),
DEVICE_FLG(0x413c, 0xa506, /* Dell AE515 sound bar */
QUIRK_FLAG_GET_SAMPLE_RATE),
+ DEVICE_FLG(0x534d, 0x0021, /* MacroSilicon MS2100/MS2106 */
+ QUIRK_FLAG_ALIGN_TRANSFER),
DEVICE_FLG(0x534d, 0x2109, /* MacroSilicon MS2109 */
QUIRK_FLAG_ALIGN_TRANSFER),
DEVICE_FLG(0x1224, 0x2a25, /* Jieli Technology USB PHY 2.0 */
Thanks for reading and considering this patch.
John Veness
More information about the Alsa-devel
mailing list