From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Flax Subject: Re: [PATCH v8] ASoC: bcm2835: Add 8 channel (multitrack) capability Date: Sat, 25 Feb 2017 16:04:38 +1100 Message-ID: References: <1486422576-6958-1-git-send-email-flatmax@flatmax.org> <1487746600-11065-1-git-send-email-flatmax@flatmax.org> <20170224121832.GA19227@camel2.lan> <3b693ff9-b3a6-1c10-5b1a-78be04006113@flatmax.org> <20170224202553.GA28529@camel2.lan> <501e4af5-51b7-c124-4a29-ef5804d8a03c@flatmax.org> <20170224230159.GA30456@camel2.lan> <27367161-11c6-2d62-cea0-f8936d8477e8@laposte.net> <1dd0f2a2-0927-f700-1c45-22538d7c9820@flatmax.org> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from nsstlmta06p.bpe.bigpond.com (nsstlmta06p.bpe.bigpond.com [203.38.21.6]) by alsa0.perex.cz (Postfix) with ESMTP id 8A8AC2670B5 for ; Sat, 25 Feb 2017 06:04:44 +0100 (CET) In-Reply-To: <1dd0f2a2-0927-f700-1c45-22538d7c9820@flatmax.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: emmanuel.fuste@laposte.net, Matthias Reichl Cc: alsa-devel@alsa-project.org, Stephen Warren , Lee Jones , Phil Elwell , Eric Anholt , Mark Brown , Florian Meier , linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org List-Id: alsa-devel@alsa-project.org On 25/02/17 13:38, Matt Flax wrote: > > > On 25/02/17 11:08, Emmanuel Fust=E9 wrote: >> Le 25/02/2017 =E0 00:02, Matthias Reichl a =E9crit : >>> 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. >> After reading this long thread and gluing all info together, my guess = >> is that the "real" thing he's trying to do is to introduce a new DPS = >> mode which is nothing more than a multichannel capable I2S mode or a = >> "DSP I" mode : DSP A with data_delay 1. >> As it is basically an I2S (2 channel) encapsulation of multichannel = >> stream, the real question is alsa plugin or new bastardized DSP mode ? >> > > I am not sure if creating a new DSP mode is necesary ? > > Having a conflict over DSP mode is a "red herring". Below we talk = > about clocking and timing mater, it is likely that that is where the = > real problem is. > >>> >>>> 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/audioinj= ector-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? >> I suspect that the FPGA act as an I2S <=3D> DSP A translator, taking = >> care of data_delay difference translation relative to the falling = >> edge of LRCLK. >> It could translate the duration of the one BCLK duration of LRCLK DSP = >> A pulse to standard I2S LRCLK even if most codecs works with I2S fs = >> LRCLK timing as the sync point is the falling edge. >> As the FPGA has to deals with the clocks of the two sides, it's more = >> simple if it's the master. >> If I'm right, the real used mode from the soc point of view is I2S = >> and all of this is valid for all I2S IP, there is nothing BMC2835 = >> specific here. It is not the right place to do the mod. >> > > > That is right, the functionality doesn't exist in ALSA to have neither = > the codec nor the SoC as master. > As I have mentioned before, this is really window dressing for the = > lack of functionality currently in ALSA. > > Consider that the same problem exists for sample rate converter chips, = > it isn't only the Audio Injector Octo's use case. > > I would like to change focus to the missing piece of the puzzle where = > an FPGA or ASIC is bit and frame master. For example a new definition : > #define SND_SOC_DAIFMT_ABM_AFM (5 << 12) /* ASIC clk & FRM = > master */ > > Now with this new mode, it will force all codecs and SoC drivers to = > fail EINVAL unless they have been manually set up to handle an ASIC = > master. > > This also solves the problem Mattias brought up where choosing DSP = > mode and codec master causes this terrible channel swapping and bit = > offset. Now we fail if in DSP mode with a codec master, or succeed in = > DSP mode with an ASIC master : > > Example for the bcm2835_is2.c : > > /* In DSP mode, ensure that an ASIC is master */ > if ((dev->fmt & SND_SOC_DAIFMT_FORMAT_MASK) > =3D=3D SND_SOC_DAIFMT_DSP_A) > if ((dev->fmt & SND_SOC_DAIFMT_MASTER_MASK) > !=3D SND_SOC_DAIFMT_ABM_AFM ) > return -EINVAL; > else > return snd_pcm_hw_constraint_single(substream->runtime, > SNDRV_PCM_HW_PARAM_CHANNELS, 8); > I am sending a patch set which implements this concept to the list. Matt