A2B codec chain implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Automotive Audio Bus (A2B) is a bus that carries a clock, I2S/TDM, I2C,
GPIO and mailboxes over a two wire connection that carries power as
well. It has a leader-follower (master-slave in the spec) structure,
with no obligation to have all samples going from or to the leader.

Analog Devices sells transceivers, that can also decode PDM inputs.
Their configuration is register based, with ways of accessing follower
registers from the leader. Here is their technical reference:
https://www.analog.com/media/en/technical-documentation/user-guides/AD242x_TRM_Rev1.1.pdf

The goal is to implement support for those, when the host is connected
to the leader. The implementation would be done by registering a new
bus_type and device_type, with a device for each functionality (on each
bus node) provided by the bus. Two issues were faced though:

 - At runtime, when an PCM stream is started, not only do the CPU and
   codec need to be configured, but also the leader and follower need
   some dynamic configuration based on hw_params. We have something
   resembling a chain, and all 4 devices need to be configured
   I2S-wise:
   CPU <-I2S-> leader node <-A2B-> follower node <-I2S-> codec.
   That does not fit the standard form of a DAI link that only has a CPU
   and a codec. Is there a way to have a sound card that contains
   multiple codecs, all actived?

 - Clocks will have to be handled at the bus level and not at the
   soundcard level, as the master clock is needed at all times for the
   bus to be functional. Sadly it's probably not doable to use the
   clocks provided by the I2S/TDM CPU codec (which would be ideal as
   they are audio rate, which is what the bus expects), because they
   only get enabled when a PCM stream is active. On the hardware used
   for testing (SAMA7G54), we can't use an external (relative to the
   CPU codec) clock as master clock and use the peripheral to generate
   the bitclock, it doesn't support it; therefore both have to be
   handled at the bus level using board specific clocks.

So the first point is the main question: how could a codec chain be
modeled?

I was potentially thinking about a custom soundcard? That could surely
help? Would it be the right solution? Any pointers would help.

The clock aspect would have been an issue as a codec is either a clock
provider or consumer but for this particular use it is not as we'll use
the bus and not the soundcard to handle the clock management.

Thanks!

Théo

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux