linux-kernel - Re: [alsa-devel] [PATCH] ASoC: bdw-rt5677: channel constraint support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <34604b9a-f479-3f92-7917-84f295a82fd8@linux.intel.com>
Date:   Thu, 12 Sep 2019 08:06:35 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     "Lu, Brent" <brent.lu@...el.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Cc:     "Rojewski, Cezary" <cezary.rojewski@...el.com>,
        "kuninori.morimoto.gx@...esas.com" <kuninori.morimoto.gx@...esas.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "yang.jie@...ux.intel.com" <yang.jie@...ux.intel.com>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "liam.r.girdwood@...ux.intel.com" <liam.r.girdwood@...ux.intel.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: bdw-rt5677: channel constraint support

On 9/12/19 1:00 AM, Lu, Brent wrote:
>>>
>>> The story is Chrome has a tool called alsa_conformance_test which runs
>>> capture or playback against a PCM port with all possible
>>> configurations (channel, format, rate) then measure if the sample rate
>>> is correct. Since the channel max number reported is 4, it tests the
>>> 4-channel 48K capture and reports the actual sample rate is 24000
>>> instead of 48000. That's the reason we want to add a constraint in
>>> machine driver to avoid user space programs trying to do 4 channel
>> recording since this machine does not support it in the beginning.
>>
>> ok, that helps get context, thanks for the details.
>>
>> I would have expected some error to be returned if there's a front-end
>> opened with 4 channels and the back-end only supports two. Adding the
>> constraint seems like a work-around to avoid dealing with the mismatch
>> between FE and BE. I don't understand DPCM enough to suggest an
>> alternative though. Ranjani, can you help on this one?
>>
>> And even if we agree with this solution, it'd be nice to apply it for the
>> Broadwell machine driver for consistency.
> 
> It's not only the mismatch but also the design limitation. According to the
> information from google, the board (samus) only uses two microphone so
> 3 or 4 channel recording are not supported. That's the reason we leverage
> the constraint from other machine driver (like kbl_da7219_max98357a.c)
> to remove the 3 and 4 channel recording option.

The design limitation is already handled by the fact that the SSP 
operates in 2ch mode, so it's a different case from KBL where indeed the 
DMIC-based back-end can support 4 channels.

> 
> The difference after the constraint is implemented is that the
> snd_pcm_hw_params_set_channels() function will return error (Invalid
> argument) when channel number is 3 or 4 so the application knows the
> configuration is not supported.

I get the error, I am just wondering if the fix is at the right 
location. I'll look into it, give me until tomorrow.