Functionality of pcm_notify in snd-aloop?

[Kai Vehmanen]

Hey,

On Thu, 30 Apr 2020, Jaroslav Kysela wrote:

> Dne 28. 04. 20 v 18:19 Kai Vehmanen napsal(a):
>> 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/87b298106e04054489ee93b26a610e37f99a3171
[...]
>> 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/a2ba541ea0b3e86a65687de88a41f10cf0a8ddc2
>
> 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.

yes, the above patch for alsa-utils is just a hack for testing 
(I used snd_pcm_resume() as that has retry-after-delay logic already 
so does what I need to restart after -ENODATA).

That's a good question whether ALSA should provide a mechanism to 
wait and/or signal when the stream can be started.

This is not clear in the generic case. There can be scenarios where the 
-ENODATA state is not transient (e.g. a monitor is not connected). So the 
application has to have some out-of-band information on how the device 
behaves -- i.e. when it makes sense to wait. For the DSP echo reference 
case, we are now proposing to describe this in UCM, so applications (like 
Pulseaudio and CRAS) can get this information from there.

For many related scenarios, we are already successfully using controls 
to inform user-space that a given PCM is ready for use (newer drivers use
this for HDMI monitor hotplug).

But it's true, even if application knows in which order to trigger the 
PCMs and how they are dependent, some retry logic needs to be used 
(especially around xrun/suspend handling). In my test code, I just simply 
used a delay-and-retry in the slave arecord instance, but a real-life 
application would use something more deterministic.

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

This could be cleaner, but a much bigger change (for applications, 
alsa-lib and drivers as well). Considering this is quite niche and 
majority of apps won't care, having applications handle -ENODATA with 
out-of-band means might still be the right-sized solution. At least the 
CRAS developer feedback so far has been that -ENODATA is sufficient.

But yeah, if there are other users/scenarios that need to wait on 
link-availability, maybe adding it to ALSA API directly, might make sense.

Br, Kai