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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
