[pulseaudio-discuss] alsa sink latency - how to account for startup delay

[Tanu Kaskinen]

On Thu, 2016-03-24 at 13:24 +0100, Georg Chini wrote:
> On 24.03.2016 10:36, Tanu Kaskinen wrote:
> > 
> > On Wed, 2016-03-23 at 14:59 +0100, Georg Chini wrote:
> > > 
> > > On 23.03.2016 14:00, Tanu Kaskinen wrote:
> > > > 
> > > > You confirmed that pa_alsa_safe_delay() returns values that increase
> > > > whenever we write more data. That indicates that the smoother is not to
> > > > blame. If you substract the current ring buffer fill level from the
> > > > delay value, the result should be constant. It sounds like it isn't,
> > > > and that's a driver bug.
> > > Not sure if I would call it a bug since the delay is reported correctly
> > > by pa_alsa_safe_delay(). I think pulseaudio should be aware of such
> > > behavior and be able to handle it.
> > It is a bug, because of how the "delay" term is defined. If a sample is
> > written to the ring buffer now, the delay tells how long it takes to
> > reach the DAC. See
> > http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga012e8b999070e72ab23514f25e7d6482
> > 
> Yes, that is exactly what the delay reports in steady state. Only during
> startup it is different. If you assume, that there is no fixed buffer on
> the alsa side but that the code is just waiting for the device to start up
> and is buffering data during that time, it cannot report more delay than
> the amount of audio you already provided. The device might start
> playing any time. So where do you see the bug?
> 
> You are however right, if there is some fixed buffer on the alsa side, then
> this should be included from the start, but I don't think there is. I will
> check the alsa code to see if I can find out more.

I expect there to be a fixed buffer. It doesn't make sense to me that
the driver would consume data from the ring buffer when the full
pipeline isn't yet running. I don't know much about what the different
PCM device states really are supposed to mean, but I would expect that
snd_pcm_prepare() already starts most of the sound card hardware, and
snd_pcm_start() just connects the application buffer to the rest of the
audio pipeline.

-- 
Tanu