archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <>
To: "Lu, Brent" <>,
	"" <>
Cc: "Rojewski, Cezary" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	Ranjani Sridharan <>
Subject: Re: [alsa-devel] [PATCH] ASoC: bdw-rt5677: channel constraint support
Date: Thu, 12 Sep 2019 08:06:35 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

  reply	other threads:[~2019-09-12 13:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06  1:24 Brent Lu
2019-09-06 14:20 ` [alsa-devel] " Pierre-Louis Bossart
2019-09-09  6:34   ` Lu, Brent
2019-09-09 17:53     ` Pierre-Louis Bossart
2019-09-10  8:28       ` Lu, Brent
2019-09-10 14:12         ` Pierre-Louis Bossart
2019-09-12  6:00           ` Lu, Brent
2019-09-12 13:06             ` Pierre-Louis Bossart [this message]
2019-09-27 12:34               ` Lu, Brent

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [alsa-devel] [PATCH] ASoC: bdw-rt5677: channel constraint support' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).