[PATCH 2/2] mf/sar: Request a new sample immediately if the buffer is too empty.

[Giovanni Mascellani]

Hi,

Il 22/06/21 10:35, Nikolay Sivov ha scritto:
> How SAR handles that on Windows? Could we simply adjust a number of
> requests that sink sends, based on "audio client buffer size" /
> "incoming sample buffer size".

I don't know how Windows' SAR does this. Is there I way I can 
instantiate Windows' SAR using an IAudioClient provided by me? It seems 
that it will only take device from the MMDeviceEnumerator provided by 
Windows itself.

The incoming sample buffer size is not known in advance, and it can vary 
a lot even within the same stream. It can go from 128 to 1024 frames at 
least. I guess it is a byproduct of how the decoder works and how 
packets are laid in the encoded file, as well as of the internals of any 
other transform in the media session. I don't know much about how 
Vorbis, but I guess we shouldn't depend on any assumption on how large 
the samples are: if we receive small samples, we just have to ask for 
more until our playback buffer is full enough.

> I don't think you should touch this event yourself, when it's supposed
> to be signaled by the audio system.

I don't think it is a problem if we touch that event. From my 
understanding it's not something that IAudioClient is supposed to use 
internally. It's just a way for IAudioClient to signal that it is ready 
to process a buffer. If we signal more often than that it's not an issue 
for the IAudioClient and certainly not for the event itself.

I can implement the same change without manually signalling the event, 
though. The reason I did it this way is that it mostly fit the current 
SAR architecture, so it doesn't require a lot of changes.

BTW, as I write you I realize that my patch is even too much, I am 
sending an updated version (that still fixes the bug on Borderlands 3, 
Deep Rock Galactic and Mutant Year Zero). This revision is still 
event-based, but if you insist on a different solution I'll rework it.

Basically the only important point is that when a new sample is received 
the queue is immediately processed, and not just once per IAudioClient 
period. Manually signalling the event seems to me the easiest and 
cleanest way to have that, but if you don't like it I can implement it 
another way.

Thanks for the review, Giovanni.