On 10/14/22 18:05, Théo Lebrun wrote:
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_T...
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.
Hi,
Daniel, me and a few others have been working on A2B driver support. We are in the process of getting it ready for upstreaming. Currently public code is in https://github.com/analogdevicesinc/linux/commits/a2bupstream. ADI squashed the commit history. We need to restore that.
At the moment the remote devices are modeled as a codec2codec link with fixed rates. Its not ideal, but the best we can do in the current ALSA framework.
I did propose some changes that will allow dynamic hwparams domain and propagation through those domains a long long time ago. But that never got to the stage where I was able to work on the implementation. See http://metafoo.de/the_new_asoc.svg
- Lars