Hello Takashi-san
On 11/11/2016 08:10 PM, Takashi Iwai wrote:
On Thu, 10 Nov 2016 08:34:41 +0100,
Jiada Wang wrote:
When configuring avail_min to multiple of slave period size it can happen
that user waits one slave period longer than needed for available data.
Root cause is implicit grabbing of slave samples in avail_update operation.
On next entering poll, the slave will wait for the avail_min threshold
reached again, as he is not aware that there are already pending samples
in the above layer which are not yet provided to user.
Solution is to dynamically adapt the avail_min on the slave.
Can you give a test case? Then it's easier to check what's going on.
Sorry, I missed your comment
Following is the error scenario
use plugin which uses the generic plugin implementation from pcm_plugin.c
(e.g linear plugin or the easiest one: 'copy' plugin)
-use MMAP capture access on that plugin
-configure slave hardware to 4ms period
-configure avail_min to 8ms
-enter snd_pcm_wait after 4ms are already available.
-->user may unexpectedly wait for 4ms too long
In general, I prefer having this only in the rate plugin, as the rate
plugin is the only one that suffers from the problem for now.
If the issue is really reproduced on other plugins, make it generic in
the plugin code later.
About your fix: the dynamic changing sw_params is hackish, so I wonder
whether it's the best solution. Let's see.
Last but not least, please try to fit within 80 chars like kernel
patches. It's not strictly required for alsa-lib codes, but still the
too long lines like in your patches are difficult to read.
Sure, I will update commit message in next update
Thanks,
Jiada
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
