<html><head></head><body>It's negligible, and most likely hidden by the rounding up to the next period.<br><br>This kind of low latency is for user interaction reaction time, e.g.  DJ applying live effects.<br><br><div class="gmail_quote">Le 25 octobre 2019 14:05:49 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2019-10-25 12:47, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">...which does not apply to a media player that is bound by the packet size.<br></blockquote><br>Even though our app feeds a certain packet size, if at the lower level <br>the OS has to mix with other sources (even with the same packet size) it <br>still needs an extra step to mix the various sources, probably adding <br>some latency.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le 25 octobre 2019 13:38:04 GMT+03:00, Thomas Guillem <thomas@gllm.fr> a <br>écrit :<br><br><br>    <a href="https://docs.microsoft.com/en-us/windows/win32/coreaudio/exclusive-mode-streams">https://docs.microsoft.com/en-us/windows/win32/coreaudio/exclusive-mode-streams</a><br><br>    "Applications that use exclusive-mode streams often do so because<br>    they require low latencies in the data paths between the audio<br>    endpoint devices and the application threads that access the<br>    endpoint buffers."<br><br><br>    On Fri, Oct 25, 2019, at 12:18, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">     I don't see how it reduces latency, no. Audio latency is largely<br>     bound by the packet/period size, not by exclusive mode.<br><br>     Le 25 octobre 2019 10:17:21 GMT+03:00, Thomas Guillem<br>     <thomas@gllm.fr> a écrit :<br><br><br><br>         On Thu, Oct 24, 2019, at 20:55, Rémi Denis-Courmont wrote:<br><br>             Le torstaina 24. lokakuuta 2019, 15.37.13 EEST Thomas<br>             Guillem a écrit :<br><br>                 cf. WASAPI_EXCLUSIVE_LONGTEXT<hr>                 modules/audio_output/wasapi.c | 174<br>                 +++++++++++++++++++++++++++++++++-<br>                 1 file changed, 170 insertions(+), 4 deletions(-)<br><br>                 diff --git a/modules/audio_output/wasapi.c<br>                 b/modules/audio_output/wasapi.c<br>                 index daa946f8afc..91defb250fb 100644<br>                 --- a/modules/audio_output/wasapi.c<br>                 +++ b/modules/audio_output/wasapi.c<br>                 @@ -588,6 +588,154 @@ static void Stop(aout_stream_t *s)<br>                 free(sys);<br>                 }<br><br>                 +/*<br>                 + * This function will try to find the closest PCM<br>                 format that is accepted<br>                 by + * the sound card. Exclusive here means a direct<br>                 access to the sound<br>                 card. The + * format arguments and the return code of<br>                 this function behave<br>                 exactly like + * IAudioClient_IsFormatSupported().<br>                 + */<br>                 +static HRESULT GetExclusivePCMFormat(IAudioClient *c,<br>                 const WAVEFORMATEX<br>                 *pwf, + WAVEFORMATEX **ppwf_closest) +{<br>                 + HRESULT hr;<br>                 + const AUDCLNT_SHAREMODE exclusive =<br>                 AUDCLNT_SHAREMODE_EXCLUSIVE;<br>                 +<br>                 + *ppwf_closest = NULL;<br>                 +<br>                 + /* First try the input format */<br>                 + hr = IAudioClient_IsFormatSupported(c, exclusive,<br>                 pwf, NULL);<br>                 +<br>                 + if (hr != AUDCLNT_E_UNSUPPORTED_FORMAT)<br>                 + {<br>                 + assert(hr != S_FALSE); /* S_FALSE reserved for<br>                 shared mode */<br>                 + return hr;<br>                 + }<br>                 +<br>                 + /* This format come from vlc_ToWave() */<br>                 + assert(pwf->wFormatTag == WAVE_FORMAT_EXTENSIBLE);<br>                 + const WAVEFORMATEXTENSIBLE *pwfe = (void *) pwf;<br>                 + assert(IsEqualIID(&pwfe->SubFormat,<br>                 &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)<br>                 + || IsEqualIID(&pwfe->SubFormat,<br>                 &KSDATAFORMAT_SUBTYPE_PCM));<br>                 +<br>                 + /* Allocate the output closest format */<br>                 + WAVEFORMATEXTENSIBLE *pwfe_closest =<br>                 + CoTaskMemAlloc(sizeof(WAVEFORMATEXTENSIBLE));<br>                 + if (!pwfe_closest)<br>                 + return E_FAIL;<br>                 + WAVEFORMATEX *pwf_closest = &pwfe_closest->Format;<br>                 +<br>                 + /* Setup the fallback arrays. There are 3 properties<br>                 to check: the<br>                 format, + * the samplerate and the channels. There are<br>                 maximum of 4<br>                 formats to + * check, 3 samplerates, and 2 channels<br>                 configuration. So,<br>                 that is a + * maximum of 4x3x2=24 checks */<br>                 +<br>                 + /* The format fallback order is dependent of the<br>                 input format. We don't<br>                 + * want to use a high quality format when it's not<br>                 needed but we<br>                 prefer to + * use a high quality format instead of a<br>                 lower one */<br>                 + static const uint16_t bits_pcm8_fallback[] = { 8,<br>                 16, 24, 32 };<br>                 + static const uint16_t bits_pcm16_fallback[] = { 16,<br>                 24, 32, 8 };<br>                 + static const uint16_t bits_pcm24_fallback[] = { 24,<br>                 32, 16, 8 };<br>                 + static const uint16_t bits_pcm32_fallback[] = { 32,<br>                 24, 16, 8 };<br>                 +<br>                 + static const size_t bits_fallback_size =<br>                 ARRAY_SIZE(bits_pcm8_fallback); +<br>                 + const uint16_t *bits_fallback;<br>                 + switch (pwf->wBitsPerSample)<br>                 + {<br>                 + case 64: /* fall through */<br>                 + case 32: bits_fallback = bits_pcm32_fallback; break;<br>                 + case 24: bits_fallback = bits_pcm24_fallback; break;<br>                 + case 16: bits_fallback = bits_pcm16_fallback; break;<br>                 + case 8: bits_fallback = bits_pcm8_fallback; break;<br>                 + default: vlc_assert_unreachable();<br>                 + }<br>                 +<br>                 + /* Check the input samplerate, then 48kHz and 44.1khz */<br>                 + const uint32_t samplerate_fallback[] = {<br>                 + pwf->nSamplesPerSec,<br>                 + pwf->nSamplesPerSec == 48000 ? 0 : 48000,<br>                 + pwf->nSamplesPerSec == 44100 ? 0 : 44100,<br>                 + };<br>                 + const size_t samplerate_fallback_size =<br>                 ARRAY_SIZE(samplerate_fallback); +<br>                 + /* Check the input number of channels, then stereo */<br>                 + const uint16_t channels_fallback[] = {<br>                 + pwf->nChannels,<br>                 + pwf->nChannels == 2 ? 0 : 2,<br>                 + };<br>                 + const size_t channels_fallback_size =<br>                 ARRAY_SIZE(channels_fallback);<br><br>             Really the only point in exclusive mode is bit exact. If<br>             you need to convert,<br>             there is really no point, especially if the sample rate<br>             and/or the channel<br>             mappings differ. This is waaaaay needlessly complicated.<br><br><br>         An other point of exclusive is to reduce the audio latency.<br><br>             -- <br>             レミ・デニ-クールモン<br>             <a href="http://www.remlab.net/">http://www.remlab.net/</a><hr>             vlc-devel mailing list<br>             To unsubscribe or modify your subscription options:<br>             <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><hr>         vlc-devel mailing list<br>         To unsubscribe or modify your subscription options:<br>         <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br><br>     -- <br>     Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez<br>     excuser ma brièveté.<hr>     vlc-devel mailing list<br>     To unsubscribe or modify your subscription options:<br>     <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser <br>ma brièveté.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>