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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, 23 Aug 2023, Amadeusz Sławiński wrote:

> The easiest way would of course be to add specific formats like:
> S20_MSB_LE
> U20_MSB_LE
> S20_MSB_BE
> U20_MSB_BE
> S24_MSB_LE
> U24_MSB_LE
> S24_MSB_BE
> U24_MSB_BE
> and one would know used formats exactly..., although I'm sure it is
> problematic in some ways, considering HDA currently exposes S32_LE and just
> sets msbits quietly and reports it after the fact to userspace.

Not just HDA but this is basicly all drivers. And this is ok in most 
cases. I mean with the MSB variants, applications can produce/consume data 
with full container bit width (like S32_LE) and for many usages, this will 
just work (the LSB data will be zero, or non-zero and ignored). Reporting 
the effective msbit is really important though, as apps _should_ check the 
field and dither when needed (although mileage varies, if you look up 
common ALSA apps, few bother to check msbit info). Anyways, this 
information definitely needs to be exposed and made available to apps.

But right, this is a bit orthogonal to the ability to _select_ a 
specific variant. That is currently not possible without your patchset.

Br, Kai




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux