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
next prev parent 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).