On Sun, 2016-03-27 at 17:50 +0200, Georg Chini wrote: > On 27.03.2016 10:47, Tanu Kaskinen wrote: > > > > On Sat, 2016-03-26 at 13:16 +0100, Georg Chini wrote: > > > > > > On 24.03.2016 13:38, Tanu Kaskinen wrote: > > > > > > For me it still looks like pulseaudio should be able to detect and handle > > > that situation. > > Why can't the alsa driver report the delay correctly from the very > > beginning? I don't see why the startup delay case would be any > > different from the normal playback delay, and if there's no difference, > > why can't the driver report the latency accurately in the beginning if > > it can report it accurately later? And what can pulseaudio do that the > > alsa driver can't? > > > > > To put it simple, the current pulseaudio code answers the question: > How long does it take for the audio to reach the alsa driver? > And I think it should answer the question: > How long does it take for the audio to reach the DAC? Which code are you talking about? pa_sink_get_latency() reports the full latency. However, the "configured latency" value only deals with the size of the alsa ring buffer, which is smaller than the full latency. module-loopback would benefit if it could set and query the "configured full latency" (which is a thing that doesn't currently exist in the code). --Â Tanu
