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

[Russell King - ARM Linux admin]

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:
> > On Tue, Mar 05, 2019 at 09:23:46AM -0500, Sven Van Asbroeck wrote:
> > > The original problem was that the fsl_ssi did not appear to work with the
> > > tda998x hdmi codec. This codec seems to be 'unique' in the sense that it
> > > needs to know the number of clocks per frame on the wire, i.e. the bclk_ratio,
> > > which no-one in alsa is providing or using at the moment.
> > > 
> > > I first made the error of conflating the physical width and the bclk_ratio,
> > > and posted this patch - Russell King quickly pointed out my error:
> > > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/145916.html
> > > 
> > > This then led to the following discussions:
> > > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145985
> > > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-February/thread.html#145947
> > > 
> > > Most of the discussion is about a mechanism to convey bclk_ratio from
> > > the frame master
> > > to the tda998x. We don't yet seem to have a consensus on how to do this best.
> > > 
> > > My rfc patch was only intended to provoke discussion, and to allow
> > > people to experiment
> > > with a flawed solution that would allow the alsa core to negotiate
> > > bclk_ratio between
> > > components. The uapi change is a serious flaw. bclk_ratio negotiation should be
> > > invisible to userspace. But I cannot see a way to accomplish this.
> > 
> > In your case:
> > 
> > +---+            +-----+
> > |CPU| <- wire -> |CODEC|
> > |DAI|            | DAI |
> > +---+            +-----+
> > 
> > So that:
> > 
> > CPU-DAI = fsl_ssi
> > CODEC-DAI = tda998x
> > wire = I2S
> > 
> > In I2S:
> >  - SCK-line = serial clock
> >  - WS-line = word select
> >  - SD-line = serial data 
> > 
> > In general I2S communication:
> >  - 2 samples are transferred in a phase of WS
> > 
> > In my opinion:
> >  - 'the number of clocks per frame on the wire' (=you need)
> >    = the number of phases of SCK per phase of WS
> > 
> > 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.
> 
> If it were to specify the on-wire format, then we'd have to multiply
> the number of in-memory formats by the number of on-wire formats.
> These are (at least): AC'97, SPDIF, I2S(Philips), I2S(Left justified),
> I2S(Right justified), two different DSP formats, and PDM.  Then for
> at least the tree I2S modes, there are the number of SCK clocks per
> sample which can be anything from the number of bits in the sample
> up to an undefined limit.
> 
> What this means is that multiplying the number of in-memory formats
> by the number of unboundable bus-specific formats leads to an
> unboundable quantity of formats.

I missed stating another point in that.  Let's say that we were to have
definitions such as:

SNDRV_PCM_FORMAT_S16_LE_I2S16
SNDRV_PCM_FORMAT_S16_LE_I2S32
SNDRV_PCM_FORMAT_S16_LE_SPDIF

We have a CPU interface that can simultaneously produce both
SNDRV_PCM_FORMAT_S16_LE_I2S32 and SNDRV_PCM_FORMAT_S16_LE_SPDIF.
However, the ALSA format negotiation is such that only _one_ format
can be negotiated between user space and kernel space.  So, one of
those has to be selected.  So, despite the hardware being perfectly
capable of producing both streams, combining the on-wire formats
with the in-memory formats means that we can't support simultaneous
operation, despite the hardware being perfectly capable.

Another point to make there is that in the general case, if a codec
supports reception of SNDRV_PCM_FORMAT_S16_LE_I2S16, then it supports
reception of SNDRV_PCM_FORMAT_S16_LE_I2S32 - the I2S bus specification
explicitly allows for more clocks than there are sample bits, and
states what happens to the extra bits.

The exception to that is when the receiving device uses the bit clock
(aka SCK) for some other purpose, such as TDA998x devices, where a
driver for such a device needs to know the ratio between the bus bit
clock and the sample rate.  As previously illustrated, ASoC has partial
support for this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up