[vlc-devel] [RFC PATCH] coreaudio: replace atomic circular buffer by locked block FIFO
thomas at gllm.fr
Tue Mar 13 09:01:51 CET 2018
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:
More information about the vlc-devel