[vlc-devel] [RFC PATCH 1/2] aout: make the play() API non blocking

[Rémi Denis-Courmont]

Le tiistaina 12. maaliskuuta 2019, 19.18.42 EET Thomas Guillem a écrit :
> TODO: implement it on all modules.
> ---
>  include/vlc_aout.h                      | 33 +++++++++++++++++++++++--
>  modules/audio_output/adummy.c           |  3 ++-
>  modules/audio_output/alsa.c             |  6 ++---
>  modules/audio_output/amem.c             |  3 ++-
>  modules/audio_output/audiotrack.c       |  6 ++---
>  modules/audio_output/audiounit_ios.m    |  7 ++++--
>  modules/audio_output/coreaudio_common.c |  7 +++---
>  modules/audio_output/coreaudio_common.h |  2 +-
>  modules/audio_output/directsound.c      | 21 ++++++++++------
>  modules/audio_output/file.c             |  5 ++--
>  modules/audio_output/jack.c             |  5 ++--
>  modules/audio_output/kai.c              |  5 ++--
>  modules/audio_output/mmdevice.c         |  5 ++--
>  modules/audio_output/mmdevice.h         |  5 ++--
>  modules/audio_output/opensles_android.c |  3 ++-
>  modules/audio_output/oss.c              |  5 ++--
>  modules/audio_output/pulse.c            |  3 ++-
>  modules/audio_output/sndio.c            |  5 ++--
>  modules/audio_output/wasapi.c           |  5 ++--
>  modules/audio_output/waveout.c          |  7 +++---
>  modules/audio_output/winstore.c         |  6 +++--
>  src/audio_output/aout_internal.h        |  1 +
>  src/audio_output/dec.c                  | 27 +++++++++++++++++++-
>  src/audio_output/output.c               |  1 +
>  24 files changed, 128 insertions(+), 48 deletions(-)
> 
> diff --git a/include/vlc_aout.h b/include/vlc_aout.h
> index 4441a42a82..770c2b7025 100644
> --- a/include/vlc_aout.h
> +++ b/include/vlc_aout.h
> @@ -112,6 +112,7 @@
>  #include <vlc_block.h>
> 
>  struct vlc_audio_output_events {
> +    void (*more_data_report)(audio_output_t *);

That's room/space in the buffer, not data.
The usually word is underflow. But if you confuse it with underrun, then 
{write,buffer}_{space,room} also works.

>      void (*drained_report)(audio_output_t *);
>      void (*timing_report)(audio_output_t *, vlc_tick_t system_now,
> vlc_tick_t pts); void (*volume_report)(audio_output_t *, float);
> @@ -123,6 +124,7 @@ struct vlc_audio_output_events {
>      int (*gain_request)(audio_output_t *, float);
>  };
> 
> +
>  /** Audio output object
>   *
>   * The audio output object is the abstraction for rendering decoded
> @@ -187,11 +189,27 @@ struct audio_output
>        * \note This callback cannot be called in stopped state.
>        */
> 
> -    void (*play)(audio_output_t *, block_t *block, vlc_tick_t date);
> +#define AOUT_PLAY_WAIT_REPORT (-1)
> +#define AOUT_PLAY_DONE (0)

Mismatched type/rank.

> +    vlc_tick_t (*play)(audio_output_t *, block_t *block, vlc_tick_t date);
>      /**< Queues a block of samples for playback (mandatory, cannot be
> NULL). *
> -      * \param block block of audio samples
> +      * As the play implementation must be non-blocking, the implementation
> is +      * allowed to return prematurely if is internal buffer is full. In
> that +      * case, the implementation must modify the block offset since
> the same +      * block will be given in a successive call and return one
> of the 3 +      * possibles values:
> +      * AOUT_PLAY_DONE: the block is fully written
> +      * AOUT_PLAY_WAIT_REPORT: aout_MoreDataReport() must be called
> +      * asynchronously from the implementation to notify the core that new
> data +      * can be written.
> +      * > 0: The core will wait for that positive delay before calling
> play() +      * again.
> +      *
> +      * \param block block of audio samples, must be released when
> returning +      * AOUT_PLAY_DONE
>        * \param date intended system time to render the first sample
> +      * \return AOUT_PLAY_WAIT_REPORT, AOUT_PLAY_DONE or a positive delay

You can just invoke the callback inline instead of AOUT_PLAY_DONE, and use a 
helper to arm a timer for the positive delay case. Then you don't need three 
different ways to handle congestion control.

But TBH, I don't really see the point in doing this *now*. As long as the 
input takes care of pacing, the problem of blocking play is negligible. That 
should be fixed in VLC 5.0 timeline.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/