[PATCH v4 2/2] mf/sar: Allow requesting more than a sample per period.

[Giovanni Mascellani]

Hi,

Il 24/06/21 10:46, Nikolay Sivov ha scritto:
> What I'm asking is, why do we need this additional estimation with
> period length, with an assumption of a number of periods per buffer,
> when we could simply aim at maximum capacity.

For the IAudioClient buffer we're already aiming at maximum capacity: in 
audio_renderer_render() as much data as possible is copied from the 
queue to the buffer, which eventually gets filled, provided that the 
queue itself does not starve. This is already properly implemented and 
my patch is not touching that.

What my patch is touching is getting sure that the queue doesn't starve, 
even if the source sends very short samples. The queue has no set 
maximum, so it doesn't make sense to say that we aim for maximum 
capacity. There is a minimum we have to respect, which is a period 
length, because audio_renderer_render() is called once per period and it 
consumes a period of data from the queue. I am aiming at two just 
because two is larger than one and I cannot see why buffering even more 
would give any advantage.

This is the reason why my patch computes the period length. From the 
point of view of the queue there are no other relevant quantities 
around. The IAudioClient buffer size has in line of principle no meaning 
for the SAR queue, and the fact that the buffer is more or less 3 * 
period is a vague convention that may not even be always true (the SAR 
could request a different buffer size, and the IAudioClient is not 
forced to honor that request), and that I don't think we should give for 
granted. We basically should just ignore that fact, at least for 
establishing the policy for the queue.

Thanks, Giovanni.