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
