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
