alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Reichl <hias@horus.com>
To: Matt Flax <flatmax@flatmax.org>
Cc: alsa-devel@alsa-project.org,
	Stephen Warren <swarren@wwwdotorg.org>,
	Lee Jones <lee@kernel.org>, Phil Elwell <phil@raspberrypi.org>,
	Eric Anholt <eric@anholt.net>, Mark Brown <broonie@kernel.org>,
	Florian Meier <florian.meier@koalo.de>,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8] ASoC: bcm2835: Add 8 channel (multitrack) capability
Date: Sat, 25 Feb 2017 00:02:00 +0100	[thread overview]
Message-ID: <20170224230159.GA30456@camel2.lan> (raw)
In-Reply-To: <501e4af5-51b7-c124-4a29-ef5804d8a03c@flatmax.org>

On Sat, Feb 25, 2017 at 08:30:03AM +1100, Matt Flax wrote:
> 
> 
> On 25/02/17 07:25, Matthias Reichl wrote:
> 
> >I'd put it in another way: it seems to me that the bcm2835 I2S
> >won't reliably sync in DSP mode A.
> >
> >
> 
> What you are explaining here is the nature of the BCM2835 responding to a
> codec master. The hardware setup you are describing is elegantly simple, but
> TOO simple.

Your patch only changes the CPU DAI driver. At this point it doesn't
matter if the codec or an external source is driving the clocks.

If the clock timing adheres to DSP mode A timing and you add code
to the the CPU DAI driver so it can operate in DSP mode A then
that should also work. If not, it's broken.

The (rather brief) publically available bcm2835 datasheet only
mentions I2S mode and my tests lead me to the conclusion that the
bcm2835 is actually expecting I2S timing, not DSP A - at least with
the current code.

> Measurements on a system which uses a codec master don't represent a robust
> implementation of multichannel with the BCM2835. My experiments (and now
> yours) have shown that the system has a bit shift and an uncontrollable
> channel drift.
> 
> Multichannel simply can't be done (on the BCM2835) without control at the
> hardware level - this requires an intermediate master control chip.
>
> The Audio Injector Octo machine driver, sets both the codec and the BCM2835
> as slaves - the FPGA is master because it has to control both the BCM2835
> and the codec's systems to get reliability. You can see the machine driver
> on github :
> https://github.com/flatmax/linux/blob/rpi-4.4.y/sound/soc/bcm/audioinjector-octo-soundcard.c
> 
> It has taken month to implement a robust solution to this problem using an
> FPGA and the result is a fantastic (Audio Injector Octo) sound card. I am
> almost certain this hardware technique can be used on all stereo I2S SoC
> chips.

Can you please provide details about the timing / protocol you are
actually using?

so long,

Hias

> 
> 
> Matt
> 

  reply	other threads:[~2017-02-24 23:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06 23:09 [PATCH] ASoC: bcm2835: Add 8 channel (multitrack) capability Matt Flax
2017-02-08 18:28 ` Mark Brown
2017-02-08 18:54   ` Matthias Reichl
2017-02-08 21:13     ` Matt Flax
2017-02-08 22:48       ` Matt Flax
2017-02-09  9:29         ` Matthias Reichl
2017-02-08 20:41   ` Matt Flax
2017-02-08 21:14     ` Matt Flax
2017-02-12 23:27 ` [PATCH v2] " Matt Flax
2017-02-13 20:51   ` Eric Anholt
2017-02-14  9:32   ` Charles Keepax
2017-02-14 20:36     ` Matt Flax
2017-02-14 20:52   ` [PATCH v3] " Matt Flax
2017-02-14 21:00     ` Matt Flax
2017-02-14 21:04   ` [PATCH v4] " Matt Flax
2017-02-15  8:30     ` Arnaud Mouiche
2017-02-22  5:15       ` Matt Flax
2017-02-15  9:24     ` Charles Keepax
2017-02-15 12:37     ` Florian Kauer
2017-02-15 19:26     ` Eric Anholt
2017-02-22  5:18 ` [PATCH v5] " Matt Flax
2017-02-22  5:20   ` Matt Flax
2017-02-22  5:22 ` [PATCH v6] " Matt Flax
2017-02-22  6:49   ` [alsa-devel] " kbuild test robot
2017-02-22 18:28   ` Mark Brown
2017-02-22 22:45     ` Matt Flax
2017-02-23 17:28       ` Mark Brown
2017-02-22  6:56 ` [PATCH v8] " Matt Flax
2017-02-24 12:18   ` Matthias Reichl
2017-02-24 13:50     ` Matt Flax
2017-02-24 20:25       ` Matthias Reichl
2017-02-24 21:30         ` Matt Flax
2017-02-24 23:02           ` Matthias Reichl [this message]
2017-02-25  0:08             ` Emmanuel Fusté
2017-02-25  2:38               ` Matt Flax
2017-02-25  5:04                 ` Matt Flax
2017-02-26 20:28                   ` Matt Flax

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=20170224230159.GA30456@camel2.lan \
    --to=hias@horus.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=eric@anholt.net \
    --cc=flatmax@flatmax.org \
    --cc=florian.meier@koalo.de \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=phil@raspberrypi.org \
    --cc=swarren@wwwdotorg.org \
    /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).