On 09/02/17 05:54, Matthias Reichl wrote:
On Wed, Feb 08, 2017 at 06:28:35PM +0000, Mark Brown wrote:
On Tue, Feb 07, 2017 at 10:09:36AM +1100, Matt Flax wrote:
case SND_SOC_DAIFMT_CBS_CFM: clk_set_rate(dev->clk, sampling_rate * bclk_ratio);
- case SND_SOC_DAIFMT_CBM_CFS:
Is this fall through deliberate?
- /* Default data delay to 1 bit.
In I2S mode, we must have 2 channels */if (params_channels(params) != 2)return -EINVAL;- case SND_SOC_DAIFMT_DSP_A:
- case SND_SOC_DAIFMT_DSP_B: data_delay = 1; break; default:
Matt, could you please include linux-rpi-kernel@lists.infradead.org in your emails?
I have joined that list now. It was included originally, but wasn't accepting my posts.
I fail to see the part where DSP modes are actually set up in the hardware. bcm2835 still seems to be operating in 2-channel stereo I2S mode, i.e. no real frame sync information at the hardware level.
From the SoC's perspective I agree with you. There is frame synchronisation at the hardware level, implemented in an master FPGA. This starts to hit at a lack of functionality in ALSA ... I will discuss more below.
If all you do is adding code to pretend the bcm2835 could do multichannel modes wouldn't it be easier to implement that as a userspace alsa plugin?
I am not familiar with how to implement all of this with a plugin ? Could you give me a little hand in describing that further ? That would mean that an asoundrc needs to be used to defined to make the system usable ? Is it something which does the unpacking for us in user space ? If this happens in user space is there extra cost/latency ?
I would like to bring up another topic here.
In my opinion some of these changes we are making in this general thread are only really window dressing.
We have 4 ways of setting up master, however all of them assume that either the codec or the SoC is master. None of them allow for intermediate digital logic between the two.
In this case there is a FPGA which is matching the system differences between the Codec and the SoC. In actual fact, the FPGA needs to be master - a fifth mode.
A similar problem exists when you are using a sample rate converter chip. For example, the DAC and ADC are running at different sample rates. In this case ALSA can't represent both of the sample rates. For that reason, the ADCs and the DACs have to be hard coded - it is nasty.
The only solution for me is to use snd_soc_dai_set_fmt in the machine driver to instruct both to enter slave mode. For what it is worth, I can also
In my opinion there is nothing wrong with making hardware level introductions, such as an ASIC/FPGA to implement the hardware. I accept the inflexibility of ALSA w.r.t. this type of situation, however the real fix is to adjust the core of ALSA. Hardware ASICS and FPGAs which are intermediatries between codecs and SoCs exist and are used in industry.
This happens to be one of those cases.
thanks Matt