On Tue, Mar 21, 2017 at 10:21:04PM +0100, Emmanuel Fusté wrote: > Le 16/03/2017 à 23:14, Matt Flax a écrit : > > > > > >On 17/03/17 08:27, Lars-Peter Clausen wrote: > >>On 03/16/2017 09:51 PM, Matt Flax wrote: > >>> > >>>On 16/03/17 06:01, Mark Brown wrote: > >>>>On Tue, Feb 28, 2017 at 09:59:29AM +0000, Charles Keepax wrote: > >>>>>On Mon, Feb 27, 2017 at 12:51:08PM +0100, Matthias Reichl wrote: > >>>>>>>I have a bcm2835 (Pi 2 and 3) SoC here. It is producing > >>>>>>>multichannel (8 > >>>>>>>out, > >>>>>>>6 in) audio. In ALSA we call that DSP mode - right ?! > >>>>>>No. DSP modes are protocol/timing specifications as I2S, PDP, > >>>>>>S/PDIF, ... > >>>>>>You can look these up in datasheets and if a chip implements such a > >>>>>>protocol you can be sure that it adheres to that standard - i.e. it > >>>>>>will sync the frames to the pulses on LRclk. > >>>>>I agree with the thoughts in this thread really if the AP doesn't > >>>>>actually support DSP A mode we shouldn't add DSP A mode. > >>>>The trouble here is that this isn't 100% clear, the specifications of > >>>>the DSP modes are such that only one edge in the LRCLK matters and so > >>>>providing you're doing mono or have exact clocking they interoperate > >>>>perfectly well. We already frequently do similar things the other > >>>>way, > >>>>most of the programmable serial ports can't actually do I2S modes > >>>>properly and rely on exact clocking to get things right when operating > >>>>as I2S since they only sync on one edge (though they can generally > >>>>generate the clocks correctly when operating as master, they just > >>>>don't > >>>>pay attention to the left/right switch edge). > >>>> > >>>>That said unless we're doing something with the data layout or similar > >>>>configuration there's a fairly strong case for putting the mangling > >>>>for > >>>>this in the core, something like just falling back to I2S mode if we > >>>>set > >>>>DSP A and so on. Which would be a lot nicer if we actually got > >>>>round to > >>>>putting mode capability information in the drivers. > >>>I agree, the data layout is already configurable in the bcm2835_i2s.c > >>>platform driver. We can already use the "snd_soc_dai_set_bclk_ratio" > >>>function to manage word offsets in our machine drivers. > >>> > >>>There is nothing which says that the bcm2835 SoC is I2S restricted in > >>>any > >>>way. In fact, the reference document says quite the opposite. > >>> > >>>In the reference "BCM2835 ARM Peripherals" pdf, they call the audio > >>>system > >>>an "APB peripheral". They are saying that it is reconfigurable and > >>>part of > >>>the AMBA family of interconnect schemes. > >>> > >>>As far as the bcm2835_i2s platform driver goes, it has implemented an > >>>AMBA > >>>protocol, where audio words are counted from the LR clock onset - for > >>>some > >>>reason people are insisting this is an I2S bus. Really our > >>>implementation is > >>>not I2S at all, because word onsets are programmable and flexible in > >>>the > >>>bcm2835_i2s.c driver. > >>AMBA/APB is the interface which connects the peripheral to the system > >>memory > >>bus. It is the interface over which the CPU does configuration register > >>writes. This has nothing and absolutely nothing to do with the I2S > >>interface > >>that is also implemented by the peripheral that is used to stream audio > >>to > >>and from external components. > >> > > > >Their (BCM reference) document [1] specifically states "It supports many > >classic PCM formats including I2S". > > > >Do agree with Mark's statement "the specifications of the DSP modes are > >such that only one edge in the LRCLK matters" ? > > > >If we look at the bcm2835 platform driver setup, it is concerned with bit > >clock counting to specify the audio data for both of the AMBA/APB channels > >from serial bitstream into memory. It has two channels into memory, > >however "it supports many classic PCM formats" ... my vote for one classic > >format is DSP mode ! > > > >Do you see a problem with that ? > > > >thanks > >Matt > >[1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf > >_______________________________________________ > > > Re-reading this document, the bcm2835 PCM IP block SHOULD support real DSP > mode, with one BCLK pulsed LRCLK, zero BCLK delay etc... > It just need to be properly setup. I've re-read the document, too, last week and noticed the framesync registers - sorry, I had completely forgotten about these. I guess it should be possible to configure the bcm2835 to DSP mode but it'd still be limited to 2 channel setups - the hardware only has 2 channel position registers for each direction. > According to the same document, you could program the bmc up to 16 32bits > channels when in master mode, so I suspect that you could go up to this > limit in slave mode. > But as it is designed, it could only use up to two of any channels among the > 16. I'm not quite sure if I can follow you on this - how would you configure 16 channels when there are only 2 channel position registers? With bclk ratio eg set to 16*32=512 BCM2835 will only transmit 2*32 bits of data (at configurable bit positions), the remaining 448 bits will be zero. so long, Hias _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
