Dne 15.3.2018 v 17:07 Liam Girdwood napsal(a): > On Thu, 2018-03-15 at 15:30 +0100, Takashi Iwai wrote: >>> It's not atm, as it was being set by the driver. Would probably mean an ABI >>> change to PCM ops or a new ioctl ? The latter wont break the ABI and the >>> default >>> value would remain if the ioctl was not called. >> >> Basically this timeout is merely for a safety, wasn't considered as a >> part of the real functionality. >> >> So, with your plan, this is exposed as a real PCM feature, as a part >> of API? For what kind of scenario / purpose? > > Use case is XRUN handling, DMA failure or FW crash detection. The shortened > timeout means we can recover far faster leaving a smaller gap in any audio. We have the non-blocking access mode for this purpose where the application can choose the state check time independently. It seems to me, that you like to resolve something else with this. The 'error' checking should be handled at the driver level in my opinion. I see only the possibility to reduce the timeout to a more appropriate value (we know all stream and buffering parameters to calculate the 'late' time limit). I agree that the current timeout is too big, but it's something outside the API as Takashi mentioned. Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
