On 6/24/21 12:01 PM, Giovanni Mascellani wrote:
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.
Does attached patch work? All we need is to queue some frames, not too , if buffer is always at least a period long, that will be okay, either 3/2 as in this example or just max_frames is fine. I'd like to keep it simple.
Thanks, Giovanni.