[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