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.
Maybe the USB alsa driver is not the only one which implements some
kind of double buffering.
So what do you think is the best way to work around the problem?
As already said, the moment the card starts really playing can be
detected by checking if
u->write_count - delay * frame_size > 0
I think the best way forward is to fix the driver, and if you don't
want to become a kernel developer, at least report the bug.
See above, I still think this is no driver bug.
If that approach goes nowhere, then we may need some workaround in
PulseAudio. I'm not sure what you see as the main problem to be worked
around. To me it seems that our initial latency reports are wrong, but
my impression is that you still think that the alsa sink should drop
samples or something, and that would somehow make the runtime latency
lower.
The problem is, that the reported latency for the USB sinks is
10 - 15ms too short. This means, if you tell module-loopback to
use 40ms latency you end up somewhere between 50 and 55ms.
The delay is not constant and is not reported anywhere, so the
configured latency of module-loopback does not really mean
anything - the next device could have 8s startup delay ...
I do not really get your last sentence.
At the beginning of our discussion my understanding was, that the
data is buffered somewhere in pulseaudio. Then we could have
dropped the audio during the startup phase. But by now I have seen
that alsa is buffering and we can't do anything to compensate.
Coming back to your nuclear powered sound card example, the
current state is, that the sound card buffers all the audio and
has a delay of a couple of days when it finally starts playing.
This should at least be reported correctly, currently pulseaudio
simply ignores it.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
