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

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 2023-08-24 9:31 AM, Jaroslav Kysela wrote:
> On 23. 08. 23 18:29, Amadeusz Sławiński wrote:

...

>> Problem with MSBITS_MAX is that if kernel reports something like this:
>>
>> FORMAT: S16_LE S32_LE
>> SUBFORMAT: STD MSBITS_20 MSBITS_MAX
>>
>> to userspace, is that userspace can't really tell if you should only
>> apply it to S16_LE or to S32_LE, or both. On the other hand if at some
>> point someone adds S64_LE format, something like:
> 
> Unfortunately, you've not got the point that the subformat contents 
> depends on the selected format. So the subformat mask is for ALL formats 
> selected in the configuration space. The only valid contents for one 
> format is when application or kernel reduces the format to single one. 
> And applications can do:
> 
> 1) set format to S32_LE
> 2) call refine
> 3) get subformat bits for single S32_LE format from the refined cfg space
> 
> In this case, queries and specific msbits selection will work. It's the 
> standard refine mechanism which works also for all other fields from the 
> parameter configuration space etc. If you look to all other fields from 
> the parameter configuration space, you cannot predict the exact 
> parameters (buffer size, period size, channels) until you do more 
> refining to set all parameters to exact values (single value).
> 
> In other words, the above example:
> 
> FORMAT: S16_LE S32_LE
> SUBFORMAT: STD MSBITS_20 MSBITS_MAX
> 
> .. means - at least one format supports maximal msbits for the given 
> format.

After reading all of this again, I'm fine with rewording MSBITS_32 to 
MSBITS_MAX.

As I do not see any other points to address here and review of v1 has no 
points to address either, I'll send v2 with this single change. If I'd 
missed anything, let me know.


Kind regards,
Czarek