[vlc-devel] [RFC PATCH 2/2] wasapi: reduce audio buffer

[Rémi Denis-Courmont]

Le 6 avril 2018 11:13:36 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>
>
>On Thu, Apr 5, 2018, at 17:24, Rémi Denis-Courmont wrote:
>> Le torstaina 5. huhtikuuta 2018, 13.36.20 EEST Thomas Guillem a écrit
>:
>> > On Thu, Apr 5, 2018, at 12:19, Rémi Denis-Courmont wrote:
>> > > In principles, the minimum safe value is twice the largest
>decoded audio
>> > > block. IIRC, WMA often makes 1 second blocks.
>> > 
>> > How come ? Do you have any sources ? Does it still apply now with
>fast CPU /
>> > decoders ?
>> 
>> Uh, this is pretty basic packet buffering concept... Downstream needs
>slightly 
>> more than one ptime to not underflow, and upstream usually needs
>between zero 
>> and one ptime to do its processing on an ongoing basis.
>
>But decoders don't take one ptime to decode one ptime, more like
>between 1/10 - 1/1000 ptime.
>
>> 
>> And then you have the safety margin. Actually, triple ptime is a good
>rule of 
>> thumb that is used in some audio software.
>> 
>> -- 
>> 雷米‧德尼-库尔蒙
>> https://www.remlab.net/
>> 
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

I don't know how long the pipeline takes to process a block (and it is not only the decoder). It depends on far too many variables, like access, demux, codec and filter complexity, and processor speed.

I do however know that it takes less than one ptime because real-time playback would otherwise not be feasible. Three ptimes make sure the audio output will not be the pipeline bottleneck (and also won't hold the aout lock). Two ptimes makes it almost sure.
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.