alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Sven Van Asbroeck <thesven73@gmail.com>
Cc: alsa-devel@alsa-project.org,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	David Airlie <airlied@linux.ie>, Takashi Iwai <tiwai@suse.com>,
	Liam Girdwood <lgirdwood@gmail.com>, Jyri Sarha <jsarha@ti.com>,
	Jaroslav Kysela <perex@perex.cz>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Mark Brown <broonie@kernel.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio
Date: Tue, 26 Feb 2019 15:45:19 +0000	[thread overview]
Message-ID: <20190226154519.e2wbvbkjynkaob4c@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAGngYiXrGNvwobKy+u8QWWsDowhTE8E7OSpVOOL1Yu9PvH-Z9w@mail.gmail.com>

On Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote:
> I notice that hdmi-codec.c supports up to 8 channels in hdmi multi-channel
> playback mode. If we had a _theoretical_ hdmi xmitter with 8chan support,
> would the bclk_ratio not be 8 x slot_size - or 8 x 32 if using an fsl_ssi
> in master mode?
> 
> This will of course never happen with the tda998x, because
>         .max_i2s_channels = 2,
> but we are thinking about a generic solution here.

The way TDA998x supports multichannel audio with I2S is as follows:

"The TDA9983B supports the NXP I2S-bus format. There are four I2S-bus
stereo input channels (AP1 to AP4), which enable 8 uncompressed audio
channels to be carried."

There is only one WS input and one SCK (bclk) input, which are common
to each of the I2S buses.

The TDA19988 reduces this down to two I2S buses, which means it
supports only up to 4 uncompressed channels.  hdmi-codec doesn't
take account of these restrictions, and just assumes the maximal
number of channels are always available.

So, given this parallel bus architecture, it means that whether we
have 2, 4, 6, or 8 channels is irrelevant to the number of bitclocks
per sample - the number of bitclocks would be the same.

I can't see how you'd extend a single I2S setup to support multi-
channel audio without either adding more I2S data lines or adding
additional WS signals (so making it e.g., a binary number).

Adding more WS signals makes the bus deviate from the I2S standard,
thereby making it impossible to connect a set of standard DACs to
such a source, whereas adding more I2S data lines, you just connect
each DAC to each I2S data line and common up the bit clock and WS
signals across all.

In other words, the TDA998x approach is really the only sane way
forward.

Now, as far as transmitter support, I believe TI Davinci SoCs use
this - my Onkyo TX-NR609 AV receiver uses a DA830 SoC as a DSP to
do the surround decode, which feeds multi-channel audio out to a
set of DACs over a parallel I2S bus.  The "mcasp" audio driver
has multiple serialisers to cope with this - see
Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt.

-- 
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-02-26 15:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-25 16:42 [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio Sven Van Asbroeck
2019-02-25 16:42 ` [RFC PATCH 2/2] ASoC: core: standardize snd_soc_dai_set_bclk_ratio() behaviour Sven Van Asbroeck
2019-02-26  0:35 ` [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio Kuninori Morimoto
2019-02-26  9:11   ` Russell King - ARM Linux admin
2019-02-26 14:53     ` Sven Van Asbroeck
2019-02-26 15:23       ` Mark Brown
2019-02-26 15:45       ` Russell King - ARM Linux admin [this message]
2019-02-26 16:21         ` Mark Brown
2019-02-26 16:31         ` Sven Van Asbroeck
2019-02-26 16:41           ` Mark Brown
2019-02-26 17:03           ` Russell King - ARM Linux admin
2019-02-27 18:36             ` Mark Brown
2019-02-26 18:46     ` Sven Van Asbroeck

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=20190226154519.e2wbvbkjynkaob4c@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=airlied@linux.ie \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=perex@perex.cz \
    --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).