Takashi, I tested with .periods_min=2 and reduced the period_max by half. The underruns reported by PulseAudio are no longer present with this modification. However, there's still something fishy here. In both cases, with 1 or 2 periods, PulseAudio seems to wake-up more often than it should with snd_pcm_poll_descriptors_revents returning a null event. See the sequence below. Not sure if the problem is a bad configuration of the timers of if the driver generates these events? I also noticed that the underrun reported with a single period are associated with the POLLOUT revent. I am not sure this is normal? Thanks for your feedback. - Pierre D: alsa-sink.c: Waking up in 157.78ms (system clock). >> WAKEUP E: alsa-sink.c: snd_pcm_poll_descriptors_revents() returned zero D: alsa-sink.c: Loop D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 321 ms; Process time: 50 ms D: alsa-sink.c: avail: 1076 (samples 269) >> This is not consistent, there are too few samples in the buffer D: alsa-sink.c: 365.42 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms D: alsa-sink.c: Not filling up, because too early. >> go back to sleep D: alsa-sink.c: Waking up in 157.71ms (system clock). >> WAKEUP E: alsa-sink.c: snd_pcm_poll_descriptors_revents() returned zero D: alsa-sink.c: Loop D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 321 ms; Process time: 50 ms D: alsa-sink.c: avail: 1136 (samples 284) >> again the buffer is still almost full and we have nothing to do D: alsa-sink.c: 365.08 ms left to play; inc threshold = 0.00 ms; dec threshold = 100.00 ms D: alsa-sink.c: Not filling up, because too early. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
