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.
