Quirks for MacroSilicon MS2100/MS2106

[Jaroslav Kysela]

On 23. 06. 22 10:24, Takashi Sakamoto wrote:
> Hi,
> 
> On Thu, Jun 23, 2022, at 16:18, Jaroslav Kysela wrote:
>> On 23. 06. 22 7:58, Takashi Iwai wrote:
>>
>>>> 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?
>>
>> I agree that we may start with a special plugin for this format. The UCM can
>> use any alsa-lib configuration now. So PA/PW should work with this very
>> specific hardware when properly configured.
>>
>> Note that we have SNDRV_PCM_FORMAT_SPECIAL for such cases. It will imply that
>> the applications will fail when the special conversion plugin is not used. The
>> minor issue may be with the silence routines (which is already with the
>> improper format).
> 
> I think the combination of format/subformat is available in the case.
> 
> Actually the odd frame format is within 16 bit slot, so SNDRV_PCM_FORMAT_U16
> or so is available. Then we can define new subformat to notify userspace; e.g.
> SNDRV_PCM_SUBFORMAT_MODEL_SPECIFIC.
> 
> The cons is that we need to add new subformat, thus update asound.h. On the
> other hand, the pros is that existent userspace stuffs still handle the odd format
> and user can hear playback sound at least even if the loudness is not expected.

It's a question if the cutted half-wave samples should be sent to D/A in this 
case. Also, if the high-bit (U16) is set, the resulting sample value for D/A 
is completely incorrect. It's not only about loudness. My opinion is to not 
use the U16 sample format for this and handle this hw as special one until the 
format is more common (which I do not expect) to extend the format list.

						Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.