On Thu, 2018-03-15 at 17:25 +0100, Jaroslav Kysela wrote:
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.
Yes, but unfortunately I'm coming across a lot of userspace who are using ALSA blocking IO as an audio synchronisation mechanism.
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.
It mostly is handled by the driver in this case, but userspace may care and is immediately notified by the IO failing. Fwiw, this is important in safety critical situations where any failure of audio could be deemed a safety risk (automotive use cases).
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.
ok, any objections if I change it directly (in the structure) from the SOF driver and have some core PCM hw_params() check that makes sure we are good for period/buffer time ?
Liam
Jaroslav