Hello everyone, Disclaimer: I've never worked in the sound/ layer, and it is possible that some of my questions are silly or obvious. Basically, I'm trying to implement some form of eARC(*) on an arm64 SoC. (*) enhanced Audio Return Channel (from HDMI 2.1) The setup looks like this: A = Some kind of audio source, typically a TV or game console B = The arm64 SoC, equipped with some nice speakers HDMI A ------> B If we look inside B, we actually have B1 = an eARC receiver (input = HDMI, output = I2S) B2 = an audio DSP (input = I2S, output = speakers) I2S ? B1 -----> B2 -----> speakers If I read the standard right, B is supposed to advertise which audio formats it supports, and A is supposed to pick "the best". For the sake of argument, let's say A picks "PCM, 48 kHz, 8 channels, 16b". At some point, B receives audio packets, parses the Channel Status, and determines that A is sending "PCM, 48 kHz, 8 channels, 16b". The driver then configures the I2S link, and forwards the audio stream over I2S to the DSP. QUESTION_1: How is the DSP supposed to "learn" the properties of the audio stream? (AFAIU, they're not embedded in the data, so there must be some side-channel?) I assume the driver of B1 is supposed to propagate the info to the driver of B2? (Via some call-backs? By calling a function in B2?) QUESTION_2: Does it ever make sense for B2 to ask B1 to change the audio properties? (Not sure if B1 is even allowed to renegotiate.) Regards. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel