[vlc-devel] [PATCH 2/3] wasapi: enable event-driven buffering

[Thomas Guillem]

https://docs.microsoft.com/en-us/windows/win32/coreaudio/audclnt-streamflags-xxx-constants#remarks

"the audio engine will signal the event handle to notify the client each time a buffer becomes ready for the client to process."

Is this the interrupt ? I don't know the internal of Windows, but for me it's just like a condition variable.

On Thu, Oct 3, 2019, at 11:17, Thomas Guillem wrote:
> 
> On Thu, Oct 3, 2019, at 11:14, Rémi Denis-Courmont wrote:
>> The interrupt is useless. It just draws energy for naught.
> 
> Which interrupt ?
> 
>> 
>> Le 1 octobre 2019 12:28:52 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>>> 
>>> On Tue, Oct 1, 2019, at 11:17, Rémi Denis-Courmont wrote:
>>>> Hi,
>>>> 
>>>> You can't do low delay with long period. That's fundamentally impossible. The end-to-end delay cannot be shorter than the period.
>>> 
>>> Yes, I will remove the mention about low delay.
>>> 
>>> And what about the forced interrupt ? 
>>> 
>>> 
>>>> 
>>>> Le 1 octobre 2019 12:07:46 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>>>>> 
>>>>> 
>>>>> On Mon, Sep 30, 2019, at 21:38, Rémi Denis-Courmont wrote:
>>>>>> Le maanantaina 30. syyskuuta 2019, 17.26.10 EEST Thomas Guillem a écrit :
>>>>>>> And remove the sleep in case of full buffer. This will improve low delay
>>>>>>> rendering.
>>>>>> I don't really see why. Low delay does not imply short buffers - so in fact, in 
>>>>>> low delay case, the buffer should never be even close to full, and thus there 
>>>>>> never should be a need to wait.
>>>>> 
>>>>> What if you are playing one second of audio, that is the case with some ogg files. Waiting from Play should not happen in most cases but it can happen anyway (if you increase the rate, or depending on the input).
>>>>> 
>>>>> By the way, Pulse audio is the only module that doesn't wait and trigger an overflow with flushing in that case (that is not very common I concede).
>>>>> 
>>>>> > 
>>>>>> And if there is a need to way because of "high" delay / advance, then the 
>>>>>> thread will be descheduled, whether it is for a time-out, or for an event.
>>>>>> This patches just forces an interrupt, which potentially inhibits power 
>>>>>> management.
>>>>> 
>>>>> The WaitForSingleObject() will be executed only if the audio buffer is full. As I said, this case should not happen often.
>>>>> I don't see how the interrupt is forced in that case.
>>>>> 
>>>>> Waiting for audio, without a guessed sleep, is a necessary step for VLC 5.0 where we may set all aout modules asynchronous (In that case, the wait will be done from an aout module own thread).
>>>>> 
>>>>> > 
>>>>>> -- 
>>>>>> レミ・デニ-クールモン
>>>>>> http://www.remlab.net/vlc-devel mailing list
>>>>>> To unsubscribe or modify your subscription options:
>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>> vlc-devel mailing list
>>>>> To unsubscribe or modify your subscription options:
>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>> 
>>>> -- 
>>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
>>>> _______________________________________________
>>>> vlc-devel mailing list
>>>> To unsubscribe or modify your subscription options:
>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>> 
>> 
>> -- 
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191003/0893bf7f/attachment.html>