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

[Nikolay Sivov]

On 6/24/21 11:30 AM, Giovanni Mascellani wrote:
> Hi,
>
> Il 24/06/21 09:52, Nikolay Sivov ha scritto:
>> So why can't we keep buffering until we have a total buffer length of
>> frames? How much is "target_queued_frames", is that 2 periods? If it
>> will accept 3 periods at maximum, is it worse to buffer 3 instead of 2?
>
> We have two places here where audio data is temporarily stored, so we
> need two policies, one for each of them:
>  * the IAudioClient buffer;
>  * the SAR queue.
>
> The IAudioClient buffer has a maximum size, which is the thing I
> simply called "buffer size" in my previous email, and if the source if
> fast enough (which usually is) it eventually gets filled anyway. This
> buffer size is usually about 3 periods, I think, but that's not
> guaranteed.
>
> The SAR queue is a queue, not a ring buffer, so it doesn't have any
> maximum size. In line of principle you can queue up as many frames as
> you wish, but that wouldn't be very sensible. The only requirement
> that you have is to queue at least a period, because the IAudioClient
> buffer will request more data in batches of a period, and if we have
> at least a period we can keep it filled easily. So for the SAR queue I
> am aiming at two periods, so we have some margin.
>
> This means that in total we're storing more or less five periods of
> audio data, two in the queue and around three in the buffer. But these
> two and three are in two different places, so you can't say to replace
> one with the other.
>
> Unless of course we decide to ditch the SAR queue altogether and copy
> frame data directly in the IAudioClient queue in ProcessSample. But I
> guess the queue was there for a reason, so I don't know if this is
> viable.

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.

>
> Giovanni.
>