[PATCH v4 2/2] mf/sar: Allow requesting more than a sample per period.
Giovanni Mascellani
gmascellani at codeweavers.com
Thu Jun 24 04:01:40 CDT 2021
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.
More information about the wine-devel
mailing list