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
