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