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

[Georg Chini]

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:
>>
>> 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.
> Do you mean that you still consider the "startup delay" to be a
> different thing than the normal delay that the device has all the time?

No, as I said this startup delay persists and is not different from
any other delay. The only problem is, that pulseaudio does not see
it and therefore reports wrong latencies.

>
> I assume that by "has been played" you mean that the audio has reached
> the speakers. If that's what you mean, I don't understand why you have
> the expectation that between the first and second write the equivalent
> amount of audio would have reached the speakers. That would imply zero
> latency after audio has left the alsa buffer.

What I am saying is just that if, let's say 10ms have passed
between two subsequent mmap_writes(), then I would expect
that 10 ms of audio have been played during that time. At least
this is true once audio is flowing (if you ignore the difference
between the clock sources). The issue is that this is not
true at the beginning of playback - exactly because there is some
latency (or startup delay as I have called it).

>> 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?

The driver reports it correctly but pulseaudio does not use the
information. And that is what pulseaudio can do - use the
information to report the latency correctly.
I am currently working on a replacement for the smoother
in alsa-sink and alsa-source and that is where my original
question came from. USB devices come with a latency range
of 0.5 to 2000 ms, but if you have at least the startup delay
as minimum latency, this range does not make sense.

I could actually do the same thing as the current code does
and simply ignore it. The only consequence would be that with
module-loopback you would not get the requested latency but
some milliseconds more. I don't like this solution however,
because I think you should get what you asked for.
What makes things difficult is that you have some static
and non-configurable part of the latency that can only be
detected at run-time in addition to the usual configurable sink
latency.

The motivation for replacing the smoother is that the current
latency reports are not reliable enough to make use of the
full potential of module-loopback. My goal was to reach the
precision level of zita-aj bridge (which claims to have
nanosecond precision but hasn't).
>
>> 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.
> Do you mean is it incorrect use of the alsa API to ever call
> mmap_begin() without a corresponding mmap_commit() call? It's probably
> fine. According to the documentation the purpose of mmap_commit() is to
> update the write pointer, but since we don't write anything in the
> "!after_avail && frames == 0" case, the write pointer doesn't need
> updating.
>
Thanks, that answers my question.