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

[Nikolay Sivov]

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.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 3816 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210624/25bb543d/attachment.bin>