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

[Giovanni Mascellani]

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.

Giovanni.