[vlc-devel] [PATCH] wasapi: use a finer sleep precision

Thomas Guillem thomas at gllm.fr
Wed May 27 21:00:28 CEST 2020


Hello,

On Fri, May 22, 2020, at 20:02, Rémi Denis-Courmont wrote:
> Le perjantaina 15. toukokuuta 2020, 9.45.07 EEST Thomas Guillem a écrit :
> > On Thu, May 14, 2020, at 17:14, Rémi Denis-Courmont wrote:
> > > Le torstaina 14. toukokuuta 2020, 17.09.55 EEST Thomas Guillem a écrit :
> > > > Using the device period and the remaining block sample.
> > > 
> > > Doesn't make much sense to me. Could end up with insanely short or worse
> > > insanely long waits.
> > 
> > It could end with short wait indeed. According to my debug, each time a Play
> > need to wait, one wait is enough to fill the remaining buffer (So I never
> > saw 2 consecutive sleep() from a
> 
> I don't think there is much to draw from this, as the block duration stems 
> from the codec and codec parameters, not the output. And there are no 
> particular reasons not to support arbitrary duration anyway.
> 
> > Before, we always waited for the audio buffer / 2.
> 
> That seems correct. The typical recommendation is half or a third, to keep 
> safely away from buffer underrun, all the while minimizing wakeups and power 
> usage.
> 
> > This caused the audio
> > decoder to be paused for quite a long time. When woke up, the decoder was
> > in "burst" mode and decoded again everything it could until paused again.
> 
> Yes, that's exactly how it's supposed to operate, race to idle. Do as much as 
> possible as rarely as possible.

Indeed, that way, it produces much less wake & sleep.

Anyway, I thought it fixed some underflow in some very rare situation, but the issue was elsewhere.

Thanks for the explanation.

> 
> -- 
> Реми Дёни-Курмон
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list