Re: [RFC PATCH 01/17] ALSA: pcm: Introduce MSBITS subformat interface

[Takashi Iwai <tiwai@suse.de>]

On Tue, 22 Aug 2023 17:29:47 +0200,
Jaroslav Kysela wrote:
> 
> On 22. 08. 23 17:07, Takashi Iwai wrote:
> > On Tue, 22 Aug 2023 17:03:02 +0200,
> > Jaroslav Kysela wrote:
> >> 
> >> On 11. 08. 23 18:48, Cezary Rojewski wrote:
> >> 
> >>> +#define SNDRV_PCM_SUBFMTBIT_MSBITS_32	_SNDRV_PCM_SUBFMTBIT(MSBITS_32)
> >> 
> >> What was reason to add 32/32 format ? Subformat STD + msbits == 32
> >> should already handle the maximal resolution. Until we do not have 64
> >> bit formats, it seems like an useless extension.
> > 
> > My understanding is to distinguish the cases "we do fully support
> > 32bit" and "we don't care".  But, the end effect is same for both,
> > user-space would handle 32bit in both cases, so this difference won't
> > help much, indeed.
> 
> I don't think that we have a "do not care" situation. The applications
> currently expects to use the maximal msbits for STD subformat. The
> subformat should be used only to refine (downgrade) the resolution on
> the driver / hw side on demand. I would just add only necessary API
> extensions and save one bit for now.

Well, the current behavior (with STD) is to choose whatever 32bit
format the driver supports, and the driver may set a different value
of hw_params.msbits at hw_params.  The explicit MSBITS_32 would
enforce the hw_params.msbits to be 32, otherwise hw_refine would
fail.  So I see a potential difference.


Takashi