[alsa-devel] [PATCH 0/2] alsa-lib: dynamically adapt the avail_min on the slave

Jiada Wang jiada_wang at mentor.com
Fri Dec 9 06:41:05 CET 2016


Hi Takashi

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.
>
> 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.
>
not only the rate plugin is suffering from this issue,
but also other plugins which use the generic plugin implementation
(for example linear and copy plugin), so only have the fix in rate 
plugin, won't prevent the issue we are seeing.

> About your fix: the dynamic changing sw_params is hackish, so I wonder
> whether it's the best solution.  Let's see.
>
Yes, we also think this change is risky, and would like to have it be 
reviewed by community, so that we can have a more robust solution

> 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.
>
I will update ChangeLog in next update

Thanks,
Jiada
>
> thanks,
>
> Takashi
>


More information about the Alsa-devel mailing list