Dne 28. 04. 20 v 18:19 Kai Vehmanen napsal(a):
Hey,
On Tue, 28 Apr 2020, Takashi Iwai wrote:
I believe the missing piece here is a generic way to tell user-space that the stream got invalidated. This would be useful not only for aloop but can be applied in general when a stream becomes temporarily unavailable (e.g. the HDMI monitor disconnected or the DSP route switched).
ack on that. I've been preparing this patch to add -ENODATA to alsa-lib documentation: "[RFC] pcm: add documentation for -ENODATA error code handling" https://github.com/kv2019i/alsa-lib/commit/87b298106e04054489ee93b26a610e37f...
Have not yet had time to send a proper version to the list, but it's addressing specifically this need. This would serve as the interface for SOF DSP to tell that a given PCM node will not be providing data (as the DSP topology is not fully connected) [1].
To test the above, I've used a small hack to aplay/arecord that keeps trying to restart the PCM after a delay, in case -ENODATA is returned: https://github.com/kv2019i/alsa-utils/commit/a2ba541ea0b3e86a65687de88a41f10...
This code calls wrongly snd_pcm_resume() here. Also, we should really think about the whole mechanism when the stream cannot be activated (also for playback - Intel HDMI LPE driver [2]). I mean that the poll multiplexer should handle this state, too. If we don't find a way to notify the user space that the stream can be started using the poll(), we can use another interface like control API for the notifications.
We may also instroduce a new PCM state "WAIT" to wait on the hardware / link availability (SETUP -> -ENODATA -> WAIT -> use poll() for the link status -> success -> SETUP -> PREPARE) - talking about SNDRV_PCM_STATE states here.
Jaroslav
[2] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/36a4923f9bd05d4c...