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 > 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. 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. > BTW, the USB alsa driver has another very weired bug. The reported delay > is corrected some time (between 1s and 2s) after the device has started up. > This means, at the beginning the driver reports a delay that is a couple of > ms too small and then the delay suddenly jumps up to the correct value. > The real (measured) delay does not change, just the reported numbers. > This is not something that only one device or machine is doing, the effect > is visible on all devices and machines I have access to and also on > Alexander Patrakov's system. The effect is less pronounced when the USB device is > run in batch mode, then the fix up is somewhere between 1 ms and 2 ms, > but for timer based scheduling it is more than 2ms. I have no idea what's causing the jump. -- Tanu
