[alsa-devel] [PATCH v8] ASoC: bcm2835: Add 8 channel (multitrack) capability

[Matt Flax]

On 25/02/17 16:04, Matt Flax wrote:
>
>
> On 25/02/17 13:38, Matt Flax wrote:
>>
>>
>> On 25/02/17 11:08, Emmanuel Fusté wrote:
>>> Le 25/02/2017 à 00:02, Matthias Reichl a écrit :
>>>> 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/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?
>>> I suspect that the FPGA act as an I2S <=> 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)
>>                                           == SND_SOC_DAIFMT_DSP_A)
>>         if ((dev->fmt & SND_SOC_DAIFMT_MASTER_MASK)
>>                                        != 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.
>

Hey Matthias, I had an idea which may work with your setup, which 
doesn't include the FPGA.

Firstly, add a DSP mode B to the bcm2835_i2s.c driver. Set its delay to 
0. Now we have (in the bcm2835_i2s.c) DSP mode A as delay of 1 and DSP 
mode B as a delay of 0. Set your codec to DSP mode A, the CPU (bcm2835) 
to DSP mode B. This solves the bit shift issue you mentioned before.

Secondly, to try to get rid of your random channels swapping, can you 
please check and if necessary change the DMA setup in the dts (or 
elsewhere if necessary) so that it will DMA in multiples of 8 ? Don't 
know but a hunch suggests that this may fix things ... which would be 
amazing.

Matt