Re: [alsa-devel] Propagating audio properties along the audio path

From: Charles Keepax <ckeepax@opensource•cirrus.com>
To: Marc Gonzalez <marc.w.gonzalez@free•fr>
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 14:42:59 +0000	[thread overview]
Message-ID: <20190924144259.GR10204@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <0a1bd89e-c6b7-d9ce-dac2-fa324e42b31d@free.fr>

On Tue, Sep 24, 2019 at 04:26:20PM +0200, Marc Gonzalez wrote:
> 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);
> 

Ah ok yeah that seems like a pretty good option to me thus
forcing user-space to re-open at the new params.

> > 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.
> 

As yeah reconfiguring the I2S whilst it is running would be a
terrifying prospect.

Thanks,
Charles

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel