alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
	alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
	Jyri Sarha <jsarha@ti.com>, Takashi Iwai <tiwai@suse.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware'
Date: Tue, 5 Mar 2019 09:35:29 +0000	[thread overview]
Message-ID: <20190305093529.dls55rg6ftjnwobm@shell.armlinux.org.uk> (raw)
In-Reply-To: <20190305044232.GA15636@workstation>

On Tue, Mar 05, 2019 at 01:42:32PM +0900, Takashi Sakamoto wrote:
> Hi,
> 
> On Mon, Mar 04, 2019 at 11:59:52AM -0500, Sven Van Asbroeck wrote:
> > Negotiation seems to work ok, but bclk_ratio is exposed to
> > userspace via snd_pcm_hw_params, which is not acceptable.
> > 
> > Constrain bclk_ratio by:
> > - cpu   dai capabilities && rules
> > - codec dai capabilities && rules
> > - minimum bclk_ratio is sample_width * channels
> > 
> > In hw_params_choose(), pick the smallest supported bclk_ratio,
> > which should correspond to the most efficient solution.
> > 
> > If cpu and codec dais do not specify or constrain supported
> > bclk_ratios, alsa will pick sample_width * channels.
> > 
> > Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
> > ---
> >  include/sound/pcm.h         | 11 +++++++++++
> >  include/sound/soc.h         |  2 ++
> >  include/uapi/sound/asound.h |  5 +++--
> >  sound/core/pcm_native.c     | 34 +++++++++++++++++++++++++++++++++-
> >  sound/soc/soc-pcm.c         |  8 ++++++++
> >  5 files changed, 57 insertions(+), 3 deletions(-)
> 
> In UAPI of Linux sound subsystem, sample formats are represented
> in enumerators prefixed with 'SNDRV_PCM_FORMAT_'. In the enumerators,
> sample bits and padding bits are represented:
> 
>               S8 S16 S20 S24 S32 S18_3 S20_3 S24_3
> sample-bits:   8  16  20  24  32  18    20    24 (=width)
> padding-bits:  0   0  12   8   0   6    12     0
> total bits:    8  16  32  32  32  24    24    24 (=physical_width)
>  
> When indicating a certain bit ratio of BCLK/WS from userspace,
> applications use correct combination of the above format (=physical_width)
> and the number of samples per audio data frame (=channels).

You seem to be conflating the in-memory format with the on-wire format.
These are two entirely different things.  Your table above clearly shows
the in-memory format, not the on-wire format.

-- 
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

  reply	other threads:[~2019-03-05  9:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-04 16:59 [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware' Sven Van Asbroeck
2019-03-04 16:59 ` [RFC PATCH 2/4] ASoC: hdmi-codec: add support for bclk_ratio Sven Van Asbroeck
2019-03-04 16:59 ` [RFC PATCH 3/4] drm/i2c: tda998x: calculate CTS_N directly from the bclk_ratio Sven Van Asbroeck
2019-03-04 16:59 ` [RFC PATCH 4/4] ASoC: fsl_ssi: constrain bclk_ratio in i2s master mode Sven Van Asbroeck
2019-03-05  4:42 ` [RFC PATCH 1/4] alsa: make hw_params negotiation infrastructure 'bclk_ratio aware' Takashi Sakamoto
2019-03-05  9:35   ` Russell King - ARM Linux admin [this message]
2019-03-05 14:23   ` Sven Van Asbroeck
2019-03-06 15:53     ` Jaroslav Kysela
2019-03-08  4:10     ` Takashi Sakamoto
2019-03-08 12:59       ` Russell King - ARM Linux admin
2019-03-08 13:37         ` Russell King - ARM Linux admin
2019-03-08 14:29         ` Takashi Sakamoto
2019-03-08 14:55           ` Russell King - ARM Linux admin
2019-03-08 17:22         ` Mark Brown
2019-03-08 19:54           ` Jaroslav Kysela
2019-03-08 20:07             ` Sven Van Asbroeck
2019-03-08 20:49               ` Pierre-Louis Bossart
2019-03-08 21:13                 ` Mark Brown
2019-03-08 21:54                   ` Pierre-Louis Bossart
2019-03-11  8:15             ` Takashi Sakamoto
2019-03-11 15:43               ` Jaroslav Kysela
2019-03-12 15:03                 ` Mark Brown
2019-03-13  5:57                   ` Takashi Sakamoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190305093529.dls55rg6ftjnwobm@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jsarha@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=o-takashi@sakamocchi.jp \
    --cc=peter.ujfalusi@ti.com \
    --cc=thesven73@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).