[alsa-devel] [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'

[Mark Brown]

On Fri, Mar 08, 2019 at 12:59:16PM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Mar 08, 2019 at 01:10:57PM +0900, Takashi Sakamoto wrote:

> > In expectation of ALSA PCM interface for hardware for usual device:
> >  - half number of phases of SCK per phase of WC
> >    = physical_width of sample
> >    = bytes per sample

> They are not the same thing.

> Let's take SNDRV_PCM_FORMAT_S16_LE.  The in-memory layout of this format
> is two 16-bit samples next to each other in a single 32-bit word.  Their
> width is 16, their physical_width is 16, and bytes per sample is 2.

> A CPU DAI can do one of two things:

> 1) it can generate exactly 16 SCK clock cycles per sample before WS
>    changes state, leading to a total of 32 SCK clock cycles per
>    frame.

> 2) it can generate more than 16 SCK clock cycles per sample.

> Both are entirely legal and permissable under the I2S specification.
> Both look the same in memory.

> The ALSA format specification (SNDRV_PCM_FORMAT_*) does not specify
> which of these two is used on the wire - it only specifies the in-
> memory format.

Everything Russell is saying here is correct.  The actual
ABI only affects the in memory format, userspace really shouldn't care
what's going on on the wire.  However we don't have separate
infrastructure for what goes on the wire and 90% of the time you can
just translate the memory layout into a wire layout which works so we're
conflating the two in a lot of places internally which is confusing and
fragile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20190308/e67ca152/attachment.sig>