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

[Georg Chini]

On 24.03.2016 13:38, Tanu Kaskinen wrote:
> 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.
>
As far as I can tell, there is no additional buffer in between. As you
expected, snd_pcm_prepare() sets up bus streaming (at least for
playback) and sends silence until snd_pcm_start().
If I read the code right (with a big if, I don't know anything about USB),
after snd_pcm_start() we have to wait for the next URB to retire before
the first audio can be sent. And then it apparently takes a while before
the audio reaches the speakers and completion of the first chunk is
reported back to the alsa driver.

I also checked again, what exactly happens at startup.
mmap_write() fills the buffer to the expected level and then
snd_pcm_start() is called.
When mmap_write() refills the buffer the next time, some audio has
already been played. So everything looks fine on first inspection.

The expectation however would be, that during the period between
the first and second mmap_write() call an equivalent amount of
audio has been played. And that is not the case for USB devices
because of the startup delay.

For me it still looks like pulseaudio should be able to detect and handle
that situation.

Something else, when looking at mmap_write() I noticed that there is
a situation where pa_alsa_safe_mmap_begin() is not followed by a
snd_pcm_mmap_commit() when !after_avail && frames == 0.
Not sure if this is a bug.