From: Marc Gonzalez <marc.w.gonzalez@free•fr>
To: Charles Keepax <ckeepax@opensource•cirrus.com>
Cc: alsa-devel@alsa-project•org, Mark Brown <broonie@kernel•org>,
Takashi Iwai <tiwai@suse•com>,
Linux ARM <linux-arm-kernel@lists•infradead.org>,
Liam Girdwood <lgirdwood@gmail•com>
Subject: Re: [alsa-devel] Propagating audio properties along the audio path
Date: Tue, 24 Sep 2019 16:26:20 +0200 [thread overview]
Message-ID: <0a1bd89e-c6b7-d9ce-dac2-fa324e42b31d@free.fr> (raw)
In-Reply-To: <20190924135219.GQ10204@ediswmail.ad.cirrus.com>
On 24/09/2019 15:52, Charles Keepax wrote:
> In general the ALSA framework doesn't really allow for stream
> params to change whilst the stream is active. Doing so is
> also normally very hard for the types of hardware usually
> involved. For example changing the clocks on a running I2S bus,
> very difficult to get both ends to pick up those changes at
> exactly the correct sample. Some newer buses like soundwire
> have more support for things like this were the ends of the
> link can synchronise changes but even there that is normally
> used for adding/removing streams from the bus, not reconfiguring
> a running stream.
This jives with what "filt3r" wrote on #alsa-soc
"at one point we were just closing the stream (somehow) if we detected
a change in e.g. sample-rate, so the user-space application would fail
on snd_pcm_readi()"
snd_pcm_stop(p_spdif->capture_stream, SNDRV_PCM_STATE_DISCONNECTED);
> In your case above I would imagine the system would probably be
> setup where the DSP handles the conversion between the params
> requested from the receiver and those requested by user-space.
> One of the intentions of DPCM was to allow the backend
> (DSP-receiver here) to have different params to the frontend
> (DSP-userspace here). Although as you note you still probably
> need to add something to propagate those changes to the DSP. What
> form does the physical link between the receiver and the DSP
> take?
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
To answer your question, B1 and B2 are connected via I2S.
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-09-24 14:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 15:33 Propagating audio properties along the audio path Marc Gonzalez
2019-09-20 9:50 ` 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 [this message]
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=0a1bd89e-c6b7-d9ce-dac2-fa324e42b31d@free.fr \
--to=marc.w.gonzalez@free$(echo .)fr \
--cc=alsa-devel@alsa-project$(echo .)org \
--cc=broonie@kernel$(echo .)org \
--cc=ckeepax@opensource$(echo .)cirrus.com \
--cc=lgirdwood@gmail$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--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