From: Marc Gonzalez <marc.w.gonzalez@free•fr>
To: alsa-devel@alsa-project•org
Cc: Takashi Iwai <tiwai@suse•com>,
Linux ARM <linux-arm-kernel@lists•infradead.org>,
Jaroslav Kysela <perex@perex•cz>
Subject: Propagating audio properties along the audio path
Date: Tue, 17 Sep 2019 17:33:46 +0200 [thread overview]
Message-ID: <f7861989-8a2d-ed89-8f1f-68bad7013a34@free.fr> (raw)
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-09-17 15:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 15:33 Marc Gonzalez [this message]
2019-09-20 9:50 ` Propagating audio properties along the audio path Marc Gonzalez
2019-09-23 10:47 ` Marc Gonzalez
2019-09-24 13:52 ` [alsa-devel] " Charles Keepax
2019-09-24 14:26 ` Marc Gonzalez
2019-09-24 14:42 ` Charles Keepax
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7861989-8a2d-ed89-8f1f-68bad7013a34@free.fr \
--to=marc.w.gonzalez@free$(echo .)fr \
--cc=alsa-devel@alsa-project$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=perex@perex$(echo .)cz \
--cc=tiwai@suse$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox