Quirks for MacroSilicon MS2100/MS2106

Takashi Iwai tiwai at suse.de
Thu Jun 23 07:58:24 CEST 2022


On Wed, 22 Jun 2022 22:23:50 +0200,
John Veness wrote:
> 
> 
> 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.

The suggested code change looks OK.  So far, so good...

> 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.

Ouch, this is painful.  We haven't had any devices that require a
15 bit unsigned format, and maybe we don't want to add it to the
common standard format just for one funky device, either.  Such data
processing could be done in alsa-lib, but for the proper interaction
with the user-space, the kernel should provide some information so
that user-space can process the data accordingly.  However, we have no
proper way defined for it generically, so far.

Maybe an easy way would be to create an alsa-lib external plugin, and
apply it per device.  Jaroslav, could it be done via UCM?

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

So as a first step, we can merge the patch as is.  The rest needs more
consideration.

In anyway, for merging the patch, it has to be submitted properly in a
right format, especially including your Signed-off-by tag.  Please
refer to Documentation/process/submitting-patches.rst for details.


thanks,

Takashi


More information about the Alsa-devel mailing list