[PATCH] ALSA: pcm: comment about relation between msbits hw parameter and [S|U32] formats

[Takashi Iwai]

On Sat, 29 May 2021 05:33:53 +0200,
Takashi Sakamoto wrote:
> 
> Regarding to handling [U|S][32|24] PCM formats, many userspace
> application developers and driver developers have confusion, since they
> require them to understand justification or padding. It easily
> loses consistency and soundness to operate with many type of devices. In
> this commit, I attempt to solve the situation by adding comment about
> relation between [S|U]32 formats and 'msbits' hardware parameter.
> 
> The formats are used for 'left-justified' sample format, and the available
> bit count in most significant bit is delivered to userspace in msbits
> hardware parameter (struct snd_pcm_hw_params.msbits), which is decided by
> msbits constraint added by pcm drivers (snd_pcm_hw_constraint_msbits()).
> 
> In driver side, the msbits constraint includes two elements; the physical
> width of format and the available width of the format in most significant
> bit. The former is used to match SAMPLE_BITS of format. (For my
> convenience, I ignore wildcard in the usage of the constraint.)
> 
> As a result of interaction between ALSA pcm core and ALSA pcm application,
> when the format in which SAMPLE_BITS equals to physical width of the
> msbits constaint, the msbits parameter is set by referring to the
> available width of the constraint. When the msbits parameter is not
> changed in the above process, ALSA pcm core set it alternatively with
> SAMPLE_BIT of chosen format.
> 
> In userspace application side, the msbits is only available after calling
> ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS request. Even if the hardware
> parameter structure includes somewhat value of SAMPLE_BITS interval
> parameter as width of format, all of the width is not always available
> since msbits can be less than the width.
> 
> I note that [S|U24] formats are used for 'right-justified' 24 bit sample
> formats within 32 bit frame. The first byte in most significant bit
> should be invalidated. Although the msbits exposed to userspace should be
> zero as invalid value, actually it is 32 from physical width of format.
> 
> Signed-off-by: Takashi Sakamoto <o-takashi at sakamocchi.jp>

Thanks, applied.


Takashi