[vlc-devel] [RFC PATCH 2/2] alsa: implement non-blocking play()

[Thomas Guillem]

On Tue, Mar 12, 2019, at 22:25, Rémi Denis-Courmont wrote:
> Last I checked, we try to keep at least 100 ms buffer (or do we not anymore?) with 40 ms period, so then we'll never underrun by waiting 40 ms. But if you want to cut that for low latency filtering, there's going to be a problem.
> 
> And that's not just ALSA. All aouts will potentially need fixing.

One question: if we choose low latency, we must reduce the period too. In any case we must have buffer > period * 2, do we agree ?

If the previous statement is true, my current patch won't (theoretically) cause any underrun. Maybe it should tell the core to wait for period T instead of buffer_len / 2.
But waiting only for period might me not enough like you explained, so we may end up sleeping/waking 2 times. If we sleep 2 times, we wait for 2*T periods, that is dangerously approaching buffer starvation. That plus the fact that we'll wake the CPU way more often, so yes POLL out might be a good idea.

Thanks for your explanation anyway.

> 
> Le 12 mars 2019 23:10:12 GMT+02:00, "Rémi Denis-Courmont" <remi at remlab.net> a écrit :
>> No space is okay on a spurious basis, sure. But you don't want to busy loop or to have stupidly short timers.
>> 
>> Le 12 mars 2019 21:59:30 GMT+02:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>>> 
>>> On Tue, Mar 12, 2019, at 20:48, Rémi Denis-Courmont wrote:
>>>> 
>>>> Wait less than necessary and you might have no space. Wait more and you risk an underrun.
>>> 
>>> No space is okay. The play must be in a loop and you should always wait a little less than calculated. Maybe this approach is not precise enough, but I think it's ok for our usecase. 
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190313/677865ce/attachment.html>