On 08. 09. 23 16:36, Cezary Rojewski wrote:
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:
- set format to S32_LE
- call refine
- 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.
The subformat bitmask should be also refined/updated depending on the selected format.
https://lore.kernel.org/alsa-devel/f97bbbd5-1397-f5d3-5ccf-420ec813deac@pere...
It requires new code in pcm_lib.c and ASoC PCM core code.
Jaroslav