[vlc-devel] [RFC PATCH] coreaudio: replace atomic circular buffer by locked block FIFO

[Thomas Guillem]

On Mon, Mar 12, 2018, at 22:05, Rémi Denis-Courmont wrote:
> It is obvious that the writer(s) (Play callback) should not block the 
> reader(s) (underflow callback) if the FIFO has enough data. And the VLC 
> block FIFO implementation does not currently meet that requirement.

I don't use the vlc FIFO, but the block_Chain helper (block_ChainLastAppend). In case of underflow, this code already fill the buffer with zeros and won't block at all. Cf the following code at the end of the render callback:

/* Pad with 0 */
if (i_requested > 0)
{
    assert(p_sys->i_out_size == 0);
    p_sys->i_underrun_size += i_requested;
    memset(&p_output[i_copied], 0, i_requested);
}

> 
> But it is not obvious at all that the OS should forbid it though. If an 
> app fails its deadline, it should only compromise its own stream.

I though about using APPLE os_unfair_lock_lock for this use case. This is like a spinlock but "[...] it doesn't spin on contention, but instead waits in the kernel to be awoken by an unlock."
I think that the unfairness is not a problem here since both locking threads (the render callback and the VLC DecoderThread calling aout_DecPlay) will be automatically paced and let room for the other thread. Indeed, the render thread need a sample every 22 or 88ms, and the DecoderThread will wait for the decoder, wait in the decoder lock, or wait from the aout if the FIFO is full (2seconds).

> -- 
> Remi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel