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

[Thomas Guillem]

Ping.

On Fri, May 15, 2020, at 08:45, Thomas Guillem wrote:
> 
> 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 
> 
> Before, we always waited for the audio buffer / 2. 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. I really think we need to avoid that.
> 
> I think it can only be longer than before if the audio buffer size is 
> only 2 times the period (the minimum allowed). In such case, we should 
> only wait for the period time, I guess.

Here is the only fix I could add to my current patch:
In case of very low latency mode (that won't be in VLC 4.0), I should sleep only for the period time.

> 
> > 
> > > ---
> > >  modules/audio_output/wasapi.c | 7 ++++++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/modules/audio_output/wasapi.c b/modules/audio_output/wasapi.c
> > > index 5180e93f8e8..d338351963f 100644
> > > --- a/modules/audio_output/wasapi.c
> > > +++ b/modules/audio_output/wasapi.c
> > > @@ -107,6 +107,7 @@ typedef struct aout_stream_sys
> > >      UINT64 written; /**< Frames written to the buffer */
> > >      UINT32 frames; /**< Total buffer size (frames) */
> > >      bool s24s32; /**< Output configured as S24N, but input as S32N */
> > > +    vlc_tick_t period;
> > >  } aout_stream_sys_t;
> > > 
> > >  static void ResetTimer(aout_stream_t *s)
> > > @@ -304,7 +305,8 @@ static HRESULT Play(aout_stream_t *s, block_t *block,
> > > vlc_tick_t date) break; /* done */
> > > 
> > >          /* Out of buffer space, sleep */
> > > -        vlc_tick_sleep(sys->frames * VLC_TICK_FROM_MS(500) / sys->rate);
> > > +        vlc_tick_sleep(vlc_tick_from_samples(block->i_nb_samples,
> > > sys->rate) +                       + sys->period);
> > >      }
> > >      IAudioRenderClient_Release(render);
> > >  out:
> > > @@ -884,7 +886,10 @@ static HRESULT Start(aout_stream_t *s,
> > > audio_sample_format_t *restrict pfmt, msg_Dbg(s, "maximum latency:
> > > %"PRIu64"00 ns", latT);
> > >          msg_Dbg(s, "default period : %"PRIu64"00 ns", defT);
> > >          msg_Dbg(s, "minimum period : %"PRIu64"00 ns", minT);
> > > +        sys->period = VLC_TICK_FROM_MSFTIME(defT);
> > >      }
> > > +    else
> > > +        sys->period = 0;
> > > 
> > >      CoTaskMemFree(pwf_mix);
> > >      *pfmt = fmt;
> > 
> > 
> > -- 
> > レミ・デニ-クールモン
> > http://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