<html><head></head><body>I don't see how adding a dejitter delay changes anything. The intended play time (date) will be further away, and the core will prepend more zeroes. It's transparent.<br><br><div class="gmail_quote">Le 20 juin 2018 17:23:20 GMT+03:00, Thomas Guillem <thomas@gllm.fr> 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"><br>On Tue, Jun 19, 2018, at 19:37, 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;"> Le tiistaina 19. kesäkuuta 2018, 18.09.32 EEST Thomas Guillem a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Currently, only the pulse audio module is able to start at a given time<br> (because the API allows to start a stream corked). Every other modules will<br> start right after the VLC Start callback.<br></blockquote> <br> Err no. Start() does not have any audio data. Most audio outputs start on the <br> first Play(). And that first Play() actually conveys zero padding generated by <br> the core to time the playback correctly.<br></blockquote><br>I didn't know that. Good to know.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> <br> The problem is that this does not generally work well. It requires that the <br> latency is known correctly up-front. Not all audio drivers/hardware can <br> support this.<br> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> The problem is that the first play often need to be played in the future.<br></blockquote> <br> That's not a problem: you can always defer audio, if you know how long.<br> The opposite would be a problem.<br> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> There is often a 30/50ms pts delay (tested on current master). With the<br> future output clock, this delay should be arround the dejitter value of the<br> vlc_clock_t (200 or 500ms). No problem for pulse audio, but every other<br> modules will fail to start at this given time.<br></blockquote> <br> If the audio output makes up a poor latency estimate, then this happens. <br> That's why PulseAudio does corking instead. If you remove the corking and <br> timer from PulseAudio, PulseAudio will simply exhibit the same problem.<br> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> We have some choices:<br> <br> 1/ Simplify the date handling of aout modules: all modules behave the same<br> way, and the core handle the delay (by playing silence when needed). So we<br> move the delayed start functionally from PulseAudio to the core: this is<br> what this patch is doing.<br></blockquote> <br> This is exactly what is already being done if TimeGet() succeeds before <br> playback starts.<br></blockquote><br>So if I understand correctly: for pulseaudio, TimeGet() will fail before playback starts (because the uncork is delayed), but it's OK since this module handle the deferred start itself. <br><br>For other modules, they should return a valid TimeGet() before playback is started in order to play some silence that will correspond to the audio device hw delay. Right ?<br><br>But how do you handle, in the future clock branch, a first play that is deferred by the clock dejitter time (200-500ms) ?<br>The core need to play some silence somehow, or should every module handle it themselves ?<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 2/ Modify the aout API to handle 2 type of aout modules: one like<br> pulseaudio (that handle a play date), and all the others one.<br></blockquote> <br> And this is the only way to get things working somewhat properly within the <br> current system, where the playback time is determined ahead.<br> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> I prefer the solution 1/ since it'll ease future debugging because all<br> modules will behave the same way.<br></blockquote> <br> In other words, you want to keep the core as it is and rip out some code from <br> PulseAudio. End result: PulseAudio will work worse and the other outputs will <br> be exactly as broken as before.<br> <br> Well no thanks.<br> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> If you prefer the solution 2/, we need to think about a proper aout API.<br></blockquote> <br> I prefer solution 2 and the proper API is what we have right now.<br> <br> -- <br> 雷米‧德尼-库尔蒙<br> <a href="http://www.remlab.net/">http://www.remlab.net/</a><br> <br> <br> <br><hr><br> 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><hr><br>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>