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