Le 21/03/2017 à 23:11, Matthias Reichl a écrit :
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.
Yes, two arbitrary tdm channels out of 16. And as I and you said, the
others are not usable.
Could be useful in a TDM chained scenario , but not for what we are
talking here.
Emmanuel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
