[vlc-devel] [PATCH 1/3] coreaudio: fix first time_get return values

[Thomas Guillem]

Don't return a valid delay of 0 when the delay is still not known.

This triggered VLC drift correction from aout_DecSynchronize() and could caused
flushing of first buffers or ressampler being inserted.

This also fixes playback with audio devices having a long delay (>= 350ms).
Depending on few options (like the rate), VLC was never able to catch up with
this first valid delay (so it was flushing in loop).

This commit apply for both macOS and iOS.

cf. https://code.videolan.org/videolan/vlc-ios/issues/344
---
 modules/audio_output/coreaudio_common.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/modules/audio_output/coreaudio_common.c b/modules/audio_output/coreaudio_common.c
index 4a714f5411..267b395e3a 100644
--- a/modules/audio_output/coreaudio_common.c
+++ b/modules/audio_output/coreaudio_common.c
@@ -211,15 +211,16 @@ ca_TimeGet(audio_output_t *p_aout, vlc_tick_t *delay)
 
     lock_lock(p_sys);
 
-    vlc_tick_t i_render_delay;
-    if (likely(p_sys->i_render_host_time != 0))
+    if (p_sys->i_render_host_time == 0)
     {
-        const uint64_t i_render_time_us = p_sys->i_render_host_time
-                                        * tinfo.numer / tinfo.denom / 1000;
-        i_render_delay = i_render_time_us - vlc_tick_now();
+        lock_unlock(p_sys);
+        return -1;
     }
-    else
-        i_render_delay = 0;
+
+    mtime_t i_render_delay;
+    const uint64_t i_render_time_us = p_sys->i_render_host_time
+                                    * tinfo.numer / tinfo.denom / 1000;
+    i_render_delay = i_render_time_us - vlc_tick_now();
 
     const int64_t i_out_frames = BytesToFrames(p_sys, p_sys->i_out_size);
     *delay = FramesToUs(p_sys, i_out_frames + p_sys->i_render_frames)
-- 
2.20.1