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.